DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.
Now that I have preprocessed lines, I must actually handle them all.
An error in my command line parsing, related to switch statements, was causing every command to act as a switch so a file say called "conftest.c" would be treated as -o.
Appears that macro expansion is done after expansion as defining stuff in the middle of function-like macros has the effect as if it did not occur.
A recursive class for macro expansion might help.
The hash symbol is context sensitive. In a function like macro it turns it into a string while in an object like one it does not process the identifier.
Actually I figured out a way to do expansion without getting messy, sort of. I can use a recursive method. When the method encounters a valid identifier it checks to see if it is a macro. If it is then it is expanded and replaced. On any of the replacement results, it does it again until nothing else can be expanded.
The state of preprocessor ifs is simple, it either is true or was or never was true in the past.
I should probably not depend on C for native code generation. Such a thing could be done with Java code itself with special annotations and such. The NARF decompiler code is a bit weak for it though and does not say everything about the input code. I will have to do some kind of SSA or similar. I will need to take NARF to the next level for the most part.
Well, what I really need is a high level assembly that can work on multiple architectures and can use memory effectively, access wise that is. But not The HLA.
The HLA does not even have to be a real language, just heavy macros on top of an existing assembler. Then common code I have just uses those macros in and out between things.