Re: What's lacking: a good intermediate form

"Tony" <tony@my.net> wrote in message news:09-02-132@comp.compilers...
> Or maybe I'm making the problem to hard (?). Maybe the way to go is to
> byte the bullet and generate assembly instructions and stop worrying
> about it. Then all I'd need is a good book like the Ron Mak book was
> back in it's day. (I haven't paged thru the latest Dragon edition,
> but surely I'd be more able to assess what's there now than the last
> time I looked at it in the bookstore). It would appear that the newer
> texts are too enamoured with GC and exceptions rather than locking
> down the most needed basics. OK, so my question really is...
>
> On modern desktop hardware, would anyone even notice the reduction of
> program performance because of the rather stark non-optimised back end
> code generation? (My guess is not, for 80% of software).
>


probably not...


actually, even with rather poor assembler, one can still get within 2x
or 3x of decently good compiler output (AKA: gcc with default
settings...).


early on this was actually an encouragement:
I was able to more or less match gcc's performance on some tasks with a
crude JIT, which basically converted a good number of specialized bytecodes
for a language of mine into machine code.


of course, this sent me head-first into compiler writing (me thinking,
"well, it can't be too much more work to compile C...", but I was wrong...
an interpreter, assembler, and straightforward JIT are easy, but a full
fledged compiler is a PAIN...). sadly, it is sort of like with geometry or
physics code, namely that the code is not large, but it is a pain to write
and work on...


so, from starting out, it took about 6 months before I was compiling C code
with it, and 1.5 years later, it is not doing a whole lot more (no working
C# or Java frontends, or even a complete x86-64 backend, ...). it is like a
huge effort sink...


not to discourage you or anything, but I guess it is maybe a warning of
sorts, or at least what happened in my case...




> (I read the documentation on C-- and think it would be better to have
> an assembly language toolkit for major processors with the commonly
> generated code wrapped in C functions: setting up a stack, etc.)
>


yeah. I looked into C-- as well, and it is very different from how all my
stuff works...




meanwhile, in my effort I am left with a consideration:
it is possible I could drop my current RPN-based middle-compiler frontend
syntax, and instead replace it with one more or less based on Scheme (I am
imagining a R5RS subset, dropping continuations and using defmacro rather
than hygenic macros).


basically, my compiler is more or less split into an upper-compiler, a
middle-compiler, and a lower-compiler, although the exact border between the
middle and lower compilers is not well defined (the lower compiler is mostly
whole lots of specific code-generation functions, ... whereas the middle
compiler is mostly all of the "executive logic", ...).


the idea is that I would expose a lot more of the compiler machinery, and
include an interpreter as well, allowing a good deal more power WRT dynamic
code generation and macro processing. this could make it a lot less effort
to add new features to the compiler core.


note, it would be Scheme based, but operating at a little higher-level of
abstraction than GIMPLE or GENERIC do (technically, it would be somewhat
encroaching on the same domain as is currently occupied by the upper
compiler, leaving it as primarily a parser and code for translating from the
language-specific ASTs to more language-neutral ASTs).


I have experience writing compilers and interpreters for Scheme, as this was
actually probably the first real language I implemented, back in 2002 or so
(and, actually, a lot of the code I am using as the basis for the newer
compiler core is a descendant of this original code, the result of numerous
generations of copy-paste-edit...). but, as a cost, I somewhat changed the
APIs as part of this effort (and carved the original VM into several parts),
meaning lots of renaming and reworking... followed probably by beating the
code back into hopefully interpreting Scheme...


then, this interpreter will be more or less fused with my middle-compiler
machinery (the lower-compiler machinery is more or less retained as-is...).




however, someone else I know says that all this is very much not a good
idea...




I guess as another cost, it would make the effort of getting the C# frontend
more distant, as then I am also worring around reworking my middle compiler
as well, rather than just trying to hack on exception handling and similar
onto my existing compiler...


(however, I did technically fork with the prior middle/lower compiler, so
this new one would be used probably for C#, Java, ... whereas the old RPNIL
compiler is left for C).

Return to the comp.compilers page.
Search the comp.compilers archives again.