-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thoughts on cfront's potential improvements #84
Comments
I have undertaken the task of reworking my earlier compiler project, AMaCC, with a primary focus on its educational value and potential extensibility. I wholeheartedly acknowledge the limitations of the current C front-end implementation, including the absence of a robust AST and proper modularization. At the same time, @vacantron is dedicated to introducing the SSA based IR following his initial efforts in register allocation. I want to make sure that we avoid any significant conflicts of interest when it comes to the reworking of the C front-end. Could you please consider proposing a plan for submitting pull requests that involve minimal changes? |
No problem, for the minimal changes, I would like to try separate current parser into lexer and parser, so we can keep all lexical analyzing and grammar parsing separate and also keeps all IR related functions stays in the same place in cfront. This will only extract lexical analyzing functionality from cfront and it passes token stream to parser. |
Should we also rework the preprocessor? I think the current cfront with the compiler directives and macro expansion might cause some problems in your working. |
That sounds promising. You can track the ongoing migration to an SSA-based IR in pull request #85. |
Yes, I'm currently investigating on it, current implementation is highly unreasonable and may produces some unexpected side effect, I'll try to handle preprocessor directives in parser in a more consistent way. (token based parsing instead of manual string parsing) For the rework implementation progress, I'll keep update here. Edit 1: To completely avoid post effect, I plan to completely extract it out from lexer and parser, which expands to another file, then re-read into token pipeline in lexer and pass to parser. Edit 2: After discussion with Jserv, shecc will not have a separated preprocessor, instead, I'll focus on making it consistence in token-based parsing form. |
After successfully finishing #85 and #89, @vacantron will focus on improving the SSA IR and its related compilation process. Next, he plans to devote attention to #88, which involves an optimization phase based on SSA. In the meantime, it presents an ideal opportunity to revise and rework cfront. |
#92 is the starting point for this task. |
I recently discovered a small-scale project laroc designed to create a C99 compiler for RISC-V. This project is intended to serve as a reference for improving the frontend and code generation aspects of C compilers. |
I would like to know the reason not to have a separated pre-processor. Current pre-processing logic is mixed in both lexer and parse as special cases. If pre-processing is separated, the implementation may benefit from fewer states in lexer and less additional conditions in parser. Also new features (if planned), such as string concatenation in macro ( |
This project draws inspiration from AMaCC, which in turn was influenced by the remarkable c4. All three projects share a common theme of minimalism, emphasizing self-bootstrapping without the need for external tools. This is precisely why this project eschews the use of separate assemblers and linkers, despite being a cross-compiler. Unlike mature compilers like GCC and LLVM, where the C preprocessor (cpp) is a distinct program, in our project, cpp is integrated into the lex/parser. This approach aligns with our minimalist design philosophy. While this integration adds complexity to the existing C front-end, I believe that the benefits of a more unified design principle justify this complexity. |
As of the merge of #111, the work on cfront's job is considered temporarily completed, but still, I will leave this issue open for the following reasons:
Generally, these issues requires addition investigation to be done in order to be resolved. |
Currently cfront is using scanless parser with IR emitter binds into it, and it contains ~3000 LOC. But based on my contributions experience to industrial grade programming languages (V Lang in this case), shecc's frontend parser is lack of ease to either debug or for others to contribute (Even though shecc is meant to be educational).
Here's a list of my thoughts on improving the frontend of shecc:
And by accepting the suggestion described above, the possible major changes would be:
The text was updated successfully, but these errors were encountered: