OSDev.org
https://forum.osdev.org/

C/C++ Compiler
https://forum.osdev.org/viewtopic.php?f=2&t=33397
Page 2 of 2

Author:  Schol-R-LEA [ Wed Nov 27, 2019 9:07 am ]
Post subject:  Re: C/C++ Compiler

dseller wrote:
Any compiler that doesn't use a lexer and parser component, is bound to be ridiculously complex and redundant with code. I am really curious to see if this compiler will ever actually work, and produce a valid executable from any arbitrary piece of C code that it processes.


Unfortunately, we have no idea where this 'compiler' has gone in recently, if anywhere, since - as I mentioned in my previous post - Tilde hasn't updated the Sourceforge repo in a year, and in any case has shown a distinct lack of understanding of how version control repos are meant to work.

dseller wrote:
Also, this post:

Quote:
Defining Typed Variables for Immediate Access in Assembler


I am absolutely 100% not understanding what those assembly snippets/macros have to do with writing a C compiler :| Unless of course it has no real backend and it would emit assembler, which would be a proper design decision from ~. At least that would restrict his scope somewhat.


I have no problem with a compiler targeting assembly rather than native binaries, at least for early development, as it does leverage an existing tool to do the heavy lifting and simplifies the coding and debugging somewhat, at least at first. However, given that ~ is obsessed with source-level compatibility across different CPU modes, seems to think that the x86 is the One True ISA and no other platform is worthy of attention, and doesn't seem to grasp concepts such as 'code generation back-end', 'loose coupling', or 'separation of concerns' in the first place, I imagine your statement is true anyway.

What worries me more is that ~ still doesn't quite get that assembly code isn't typed, and that simply adding a bit of syntactic sugar won't change that. Now, a more sophisticated assembler - or a lot of macrology with a more powerful macro expander - could indeed be set up to enforce type discipline in assembly code, but that's only going to add a layer of defensive programming to the development process - it would warn you that you are doing something foolish, but it wouldn't actually make the assembly data typed, if you see my point. At the machine code level, types (or rather, operand sizes) are still a part of the opcode, not the data itself.

Author:  Alexey1994 [ Sun Jan 07, 2024 12:36 pm ]
Post subject:  Re: C/C++ Compiler

I'll just help with code. I saw the idea in the sources and documentation of lua 4.01. It's not C, but you get the idea.

https://github.com/Alexey1994/system-language-hierarchy

Page 2 of 2 All times are UTC - 6 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/