>>> Thoughts? >> >> Wow... :) You totally missed my point. >> >> My idea is to have a langage which has a lower implementation >> technical cost. That's why I was saying "the other way". > > > > Are you talking about the IL/IC, or the other one we were talking > about? Because I talked about two there, not one.
The C- one. >>> Sorry about the delay, I receive digests, so I didn't get this until >>> after I'd sent out my last message. >>> >>> The reason why C is normally not used as an IL/IC is because you can >>> design languages that are easier to parse than C. Simple as that. Your >>> stereo typical assembly language, where each line of code corresponds >>> to a single discrete action and it's arguments is much easier to parse >>> than C. So, C normally doesn't get used in that role, because someone >>> who can write a parser for any variant of C is likely to have a much >>> easier time writing a parser for some specialized language instead. >>> >>> C isn't as difficult to parse as C++, but when you consider that >>> you'll be having to parse all of this again in a completely different >>> program, it becomes easy to see why you'd favor simplicity of parsing. >> >> The whole point was to re-use the tinycc parser and keep things >> reasonnable. >> > > So you want to hook into the TCC parser itself? I said, if this has no obvious blockers, we could use fake targets that would be optimization passes. They would output C code. Regarding the unused code elimitation across compilation units, it involves probably the linker. Then the "trick" of the fake target may not be as easy. We may have to "annotate" the generated C code for the real target to insert the proper information in the object file for the linker. I bet that optimization pass would be kind of the last one. - A compilation unit scoped dead/unused code removal fake target - A C code annotation target which create a dependency tree of machine code sections for the linker to optimize out or not. Anyway, I don't think I will ever have the time to code any of this, so... _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
