BranchesTags

Repository files navigation

mocker

Build Status

Hello. If you are reading this, then probably you are taking a compiler course and going to implement your own compiler, and going to read my code. However, the quality of code varies. Hence, I wrote this down as a guide and I wish it, as well as my code, would be helpful.

Overview

This project consists of three main directories: compiler/, ir/ and ir-interpreter. Most of the code is in compiler/. The implemtation of my IR is in ir/ and I also wrote a naive interpreter for my IR. It is only a legacy issue that there are three directories.

Frontend

By frontend, I mean the parsing, semantic analysis and IRgen. The code of this part is in the corresponding subdirectories of compiler/.

Parser

I handcrafted a LL recursive descent parser. Some ad hoc hacks are used to simplify the implementation. In most cases, you can use parser generators such as ANTLR to generate your LR parser. The only reason I handcrafted a parser is that I thought it would take less time. Anyway, if you are going to implement your own LL parser, maybe you could read the comments in parse/parser.h. I wrote down the grammar there, which might be helpful.

AST

My implementation of the AST is NOT good. When I wrote that part, I was not familiar with that Java-like design pattern. Therefore, I used public fields instead of make them read-only using getter. You could see my implementation of my IR to understand what I mean here. Except this issue, there are no big problems.

Meanwhile, instead of recording everything in the AST node structure, I assign each node a unique identifier and record the need information such as types in separate containers. I think this design is better since it is much more flexible and elegant (personal opinion).

Semantic analysis

This part is quite straightforward.

IRGen

I believe my code is quite clear. On some subtle things such as translating array constructions, I wrote detailed comments (Cf. Builder::translateNewArray).

Optimization

TODO

Codegen

TODO

About

A compiler for course Compiler 2019

Topics

compiler

Resources

Readme
MIT license
Activity

Stars

16 stars

Watchers

2 watching

Forks

1 fork
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Repository files navigation
mocker
Build Status
Hello. If you are reading this, then probably you are taking a compiler course
and going to implement your own compiler, and going to read my code. However,
the quality of code varies. Hence, I wrote this down as a guide and I wish it,
as well as my code, would be helpful.
Overview
This project consists of three main directories: compiler/, ir/ and
ir-interpreter. Most of the code is in compiler/. The implemtation of
my IR is in ir/ and I also wrote a naive interpreter for my IR. It is only
a legacy issue that there are three directories.
Frontend
By frontend, I mean the parsing, semantic analysis and IRgen. The code of this
part is in the corresponding subdirectories of compiler/.
Parser
I handcrafted a LL recursive descent parser. Some ad hoc hacks are used to
simplify the implementation. In most cases, you can use parser generators such
as ANTLR to generate your LR parser. The only reason I handcrafted a parser is
that I thought it would take less time. Anyway, if you are going to implement
your own LL parser, maybe you could read the comments in parse/parser.h. I
wrote down the grammar there, which might be helpful.
AST
My implementation of the AST is NOT good. When I wrote that part, I was not
familiar with that Java-like design pattern. Therefore, I used public fields
instead of make them read-only using getter. You could see my implementation of
my IR to understand what I mean here. Except this issue, there are no big
problems.
Meanwhile, instead of recording everything in the AST node structure, I assign
each node a unique identifier and record the need information such as types in
separate containers. I think this design is better since it is much more
flexible and elegant (personal opinion).
Semantic analysis
This part is quite straightforward.
IRGen
I believe my code is quite clear. On some subtle things such as translating
array constructions, I wrote detailed comments (Cf.
Builder::translateNewArray).
Optimization
TODO
Codegen
TODO
About
A compiler for course Compiler 2019
Topics
compiler
Resources
Readme
MIT license
Activity
Stars
16 stars
Watchers
2 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
mocker
Build Status
Hello. If you are reading this, then probably you are taking a compiler course
and going to implement your own compiler, and going to read my code. However,
the quality of code varies. Hence, I wrote this down as a guide and I wish it,
as well as my code, would be helpful.
Overview
This project consists of three main directories: compiler/, ir/ and
ir-interpreter. Most of the code is in compiler/. The implemtation of
my IR is in ir/ and I also wrote a naive interpreter for my IR. It is only
a legacy issue that there are three directories.
Frontend
By frontend, I mean the parsing, semantic analysis and IRgen. The code of this
part is in the corresponding subdirectories of compiler/.
Parser
I handcrafted a LL recursive descent parser. Some ad hoc hacks are used to
simplify the implementation. In most cases, you can use parser generators such
as ANTLR to generate your LR parser. The only reason I handcrafted a parser is
that I thought it would take less time. Anyway, if you are going to implement
your own LL parser, maybe you could read the comments in parse/parser.h. I
wrote down the grammar there, which might be helpful.
AST
My implementation of the AST is NOT good. When I wrote that part, I was not
familiar with that Java-like design pattern. Therefore, I used public fields
instead of make them read-only using getter. You could see my implementation of
my IR to understand what I mean here. Except this issue, there are no big
problems.
Meanwhile, instead of recording everything in the AST node structure, I assign
each node a unique identifier and record the need information such as types in
separate containers. I think this design is better since it is much more
flexible and elegant (personal opinion).
Semantic analysis
This part is quite straightforward.
IRGen
I believe my code is quite clear. On some subtle things such as translating
array constructions, I wrote detailed comments (Cf.
Builder::translateNewArray).
Optimization
TODO
Codegen
TODO
About
A compiler for course Compiler 2019
Topics
compiler
Resources
Readme
MIT license
Activity
Stars
16 stars
Watchers
2 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
mocker
Build Status
Hello. If you are reading this, then probably you are taking a compiler course
and going to implement your own compiler, and going to read my code. However,
the quality of code varies. Hence, I wrote this down as a guide and I wish it,
as well as my code, would be helpful.
Overview
This project consists of three main directories: compiler/, ir/ and
ir-interpreter. Most of the code is in compiler/. The implemtation of
my IR is in ir/ and I also wrote a naive interpreter for my IR. It is only
a legacy issue that there are three directories.
Frontend
By frontend, I mean the parsing, semantic analysis and IRgen. The code of this
part is in the corresponding subdirectories of compiler/.
Parser
I handcrafted a LL recursive descent parser. Some ad hoc hacks are used to
simplify the implementation. In most cases, you can use parser generators such
as ANTLR to generate your LR parser. The only reason I handcrafted a parser is
that I thought it would take less time. Anyway, if you are going to implement
your own LL parser, maybe you could read the comments in parse/parser.h. I
wrote down the grammar there, which might be helpful.
AST
My implementation of the AST is NOT good. When I wrote that part, I was not
familiar with that Java-like design pattern. Therefore, I used public fields
instead of make them read-only using getter. You could see my implementation of
my IR to understand what I mean here. Except this issue, there are no big
problems.
Meanwhile, instead of recording everything in the AST node structure, I assign
each node a unique identifier and record the need information such as types in
separate containers. I think this design is better since it is much more
flexible and elegant (personal opinion).
Semantic analysis
This part is quite straightforward.
IRGen
I believe my code is quite clear. On some subtle things such as translating
array constructions, I wrote detailed comments (Cf.
Builder::translateNewArray).
Optimization
TODO
Codegen
TODO
About
A compiler for course Compiler 2019
Topics
compiler
Resources
Readme
MIT license
Activity
Stars
16 stars
Watchers
2 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Repository files navigation
mocker
Build Status
Hello. If you are reading this, then probably you are taking a compiler course
and going to implement your own compiler, and going to read my code. However,
the quality of code varies. Hence, I wrote this down as a guide and I wish it,
as well as my code, would be helpful.
Overview
This project consists of three main directories: compiler/, ir/ and
ir-interpreter. Most of the code is in compiler/. The implemtation of
my IR is in ir/ and I also wrote a naive interpreter for my IR. It is only
a legacy issue that there are three directories.
Frontend
By frontend, I mean the parsing, semantic analysis and IRgen. The code of this
part is in the corresponding subdirectories of compiler/.
Parser
I handcrafted a LL recursive descent parser. Some ad hoc hacks are used to
simplify the implementation. In most cases, you can use parser generators such
as ANTLR to generate your LR parser. The only reason I handcrafted a parser is
that I thought it would take less time. Anyway, if you are going to implement
your own LL parser, maybe you could read the comments in parse/parser.h. I
wrote down the grammar there, which might be helpful.
AST
My implementation of the AST is NOT good. When I wrote that part, I was not
familiar with that Java-like design pattern. Therefore, I used public fields
instead of make them read-only using getter. You could see my implementation of
my IR to understand what I mean here. Except this issue, there are no big
problems.
Meanwhile, instead of recording everything in the AST node structure, I assign
each node a unique identifier and record the need information such as types in
separate containers. I think this design is better since it is much more
flexible and elegant (personal opinion).
Semantic analysis
This part is quite straightforward.
IRGen
I believe my code is quite clear. On some subtle things such as translating
array constructions, I wrote detailed comments (Cf.
Builder::translateNewArray).
Optimization
TODO
Codegen
TODO
About
A compiler for course Compiler 2019
Topics
compiler
Resources
Readme
MIT license
Activity
Stars
16 stars
Watchers
2 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
mocker
Build Status
Hello. If you are reading this, then probably you are taking a compiler course
and going to implement your own compiler, and going to read my code. However,
the quality of code varies. Hence, I wrote this down as a guide and I wish it,
as well as my code, would be helpful.
Overview
This project consists of three main directories: compiler/, ir/ and
ir-interpreter. Most of the code is in compiler/. The implemtation of
my IR is in ir/ and I also wrote a naive interpreter for my IR. It is only
a legacy issue that there are three directories.
Frontend
By frontend, I mean the parsing, semantic analysis and IRgen. The code of this
part is in the corresponding subdirectories of compiler/.
Parser
I handcrafted a LL recursive descent parser. Some ad hoc hacks are used to
simplify the implementation. In most cases, you can use parser generators such
as ANTLR to generate your LR parser. The only reason I handcrafted a parser is
that I thought it would take less time. Anyway, if you are going to implement
your own LL parser, maybe you could read the comments in parse/parser.h. I
wrote down the grammar there, which might be helpful.
AST
My implementation of the AST is NOT good. When I wrote that part, I was not
familiar with that Java-like design pattern. Therefore, I used public fields
instead of make them read-only using getter. You could see my implementation of
my IR to understand what I mean here. Except this issue, there are no big
problems.
Meanwhile, instead of recording everything in the AST node structure, I assign
each node a unique identifier and record the need information such as types in
separate containers. I think this design is better since it is much more
flexible and elegant (personal opinion).
Semantic analysis
This part is quite straightforward.
IRGen
I believe my code is quite clear. On some subtle things such as translating
array constructions, I wrote detailed comments (Cf.
Builder::translateNewArray).
Optimization
TODO
Codegen
TODO
About
A compiler for course Compiler 2019
Topics
compiler
Resources
Readme
MIT license
Activity
Stars
16 stars
Watchers
2 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
mocker
Build Status
Hello. If you are reading this, then probably you are taking a compiler course
and going to implement your own compiler, and going to read my code. However,
the quality of code varies. Hence, I wrote this down as a guide and I wish it,
as well as my code, would be helpful.
Overview
This project consists of three main directories: compiler/, ir/ and
ir-interpreter. Most of the code is in compiler/. The implemtation of
my IR is in ir/ and I also wrote a naive interpreter for my IR. It is only
a legacy issue that there are three directories.
Frontend
By frontend, I mean the parsing, semantic analysis and IRgen. The code of this
part is in the corresponding subdirectories of compiler/.
Parser
I handcrafted a LL recursive descent parser. Some ad hoc hacks are used to
simplify the implementation. In most cases, you can use parser generators such
as ANTLR to generate your LR parser. The only reason I handcrafted a parser is
that I thought it would take less time. Anyway, if you are going to implement
your own LL parser, maybe you could read the comments in parse/parser.h. I
wrote down the grammar there, which might be helpful.
AST
My implementation of the AST is NOT good. When I wrote that part, I was not
familiar with that Java-like design pattern. Therefore, I used public fields
instead of make them read-only using getter. You could see my implementation of
my IR to understand what I mean here. Except this issue, there are no big
problems.
Meanwhile, instead of recording everything in the AST node structure, I assign
each node a unique identifier and record the need information such as types in
separate containers. I think this design is better since it is much more
flexible and elegant (personal opinion).
Semantic analysis
This part is quite straightforward.
IRGen
I believe my code is quite clear. On some subtle things such as translating
array constructions, I wrote detailed comments (Cf.
Builder::translateNewArray).
Optimization
TODO
Codegen
TODO
About
A compiler for course Compiler 2019
Topics
compiler
Resources
Readme
MIT license
Activity
Stars
16 stars
Watchers
2 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Repository files navigation
mocker
Build Status
Hello. If you are reading this, then probably you are taking a compiler course
and going to implement your own compiler, and going to read my code. However,
the quality of code varies. Hence, I wrote this down as a guide and I wish it,
as well as my code, would be helpful.
Overview
This project consists of three main directories: compiler/, ir/ and
ir-interpreter. Most of the code is in compiler/. The implemtation of
my IR is in ir/ and I also wrote a naive interpreter for my IR. It is only
a legacy issue that there are three directories.
Frontend
By frontend, I mean the parsing, semantic analysis and IRgen. The code of this
part is in the corresponding subdirectories of compiler/.
Parser
I handcrafted a LL recursive descent parser. Some ad hoc hacks are used to
simplify the implementation. In most cases, you can use parser generators such
as ANTLR to generate your LR parser. The only reason I handcrafted a parser is
that I thought it would take less time. Anyway, if you are going to implement
your own LL parser, maybe you could read the comments in parse/parser.h. I
wrote down the grammar there, which might be helpful.
AST
My implementation of the AST is NOT good. When I wrote that part, I was not
familiar with that Java-like design pattern. Therefore, I used public fields
instead of make them read-only using getter. You could see my implementation of
my IR to understand what I mean here. Except this issue, there are no big
problems.
Meanwhile, instead of recording everything in the AST node structure, I assign
each node a unique identifier and record the need information such as types in
separate containers. I think this design is better since it is much more
flexible and elegant (personal opinion).
Semantic analysis
This part is quite straightforward.
IRGen
I believe my code is quite clear. On some subtle things such as translating
array constructions, I wrote detailed comments (Cf.
Builder::translateNewArray).
Optimization
TODO
Codegen
TODO
About
A compiler for course Compiler 2019
Topics
compiler
Resources
Readme
MIT license
Activity
Stars
16 stars
Watchers
2 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages