> Are you coding inside your branch, or just your plugin?
> [implied] What are you actually doing?
It isn't relevant or short, but if you really want to know:
It is a front end, and indeed, a branch, it won't ever be contributed.
It is the Modula-3 frontend, which plays slight licensing games and
the original authors aren't around, so couldn't get to FSF, and current
maintainers can't either.
Honestly, long term, I'd like to generate C instead, for a variety of reasons.
- no more license game
- more portability (e.g. to platforms that also fork/maintain gcc,
so we don't have to fork and patch also theirs: e.g. OpenBSD, iPhone;
e.g. to platforms with no gcc such as NT/ia64)
- generate C++ actually, for portable usually efficient exception handling
Currently we use setjmp/longjmp and a thread local. It works and is very
portable,
but is very inefficient.
- debuggability, with stock debuggers
- solidly fix stuff I detail below
- a source distribution story
Yes, I realize, compilers must be distributed as binaries, but one can
paint the world as layered on C or C++ and then only their compilers need
binary distribution.
- I realize compile speed would suffer. And expression evaluation in debugger
would suffer. Those are the drawbacks.
Making it a plugin might be viable in the future, but I'm more keen on
generating C instead.
We also have our own frontend for NT/x86, that writes out COFF .objs, which
might be interesting to extend to others,
but that is a lot of work.
Historically we have generated very poor trees.
One particular example is that our structs have size but no fields.
I only realized this when targeting Solaris/sparc64 and hitting
assertion failures in the middle end -- the code couldn't
figure out how to pass such things.
As well, historically, we made everything volatile, in order to defeat
the optimizer. Now what we do is almost never use volatile, but still
turn off a small number of optimizations.
Nobody also had been using configure -enable-checking, and it complains
variously.
I've fixed some of that.
So I'm working on filling in types much better.
I have made good fast progress.
This also greatly improves debugging with stock gdb, instead of forked/hacked
gdb that we get debug info to in a somewhat sleazy but fairly portable way
(custom stabs, as I understand, doesn't work e.g. on HP-UX/HPPA64 or on any
MacOSX.)
However some of the types are circular, and the code currently
only makes one pass. So I simply want it to build up its own in-memory
representation, make some passes over that, and then generate the "real" trees.
The in-memory representation will contain some trees.. though I suppose
now that I explain it, there is a way around that.
The reading of the intermediate form is somewhat data driven, reading into
locals.
I want to reuse that but read into structs, and then loop over them.
Simple stuff really.
I could probably also make extra passes over the gcc trees instead,
but I'm designing partly out of ignorance. I'm not sure when you can
continue to change them vs. when they are frozen.
The non-compacting of the gc makes this easier than it might be otherwise.
Though looking at it, we already store many of our trees in global arrays.
There's just a few stragglers I can also put in global arrays and be ok.
Thanks,
- Jay
