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: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.
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.dseller wrote:Also, this post:
I am absolutely 100% not understanding what those assembly snippets/macros have to do with writing a C compilerDefining Typed Variables for Immediate Access in AssemblerUnless 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.
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.
