This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: is gcc garbage collector compacting?


 > 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
 		 	   		  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]