> I believe that your case is a very good example of why front-ends
> should be able to become plugins. It is not the case yet, and adding
Currently we do define a new tree code, I think just one.
And the implementation is *slightly* invasive.
I was tempted to write up a proposal to this list to add it to mainline gcc but
I ended up not.
I noticed the D/gcc frontend does something similar.
In particular..nested functions...taking their address..we implement them in a
way that
doesn't involve runtime codegen. Though there are significant downsides
to what we do. Having thought about it, I believe there is no particularly
good way to implemented nested functions (taking their address), just
multiple not very good ways.
What we do is, is that function pointers are rare in our language.
Before calling through any function pointer, we read the data it points to and
check for a marker -- -1, currently of size_t size, though probably should
always be 4 bytes (alignment issues), except maybe on IA64 (particularly
large instructions). This is a bit sleazy -- assumption
that code is readable and that -1 isn't valid code, but other target-dependent
markers could be specified. Anyway, if it -1, it is followed by actual function
pointer and frame pointer, and that is used instead of calling it directly.
Something like that.
The implication on the backend isn't perhaps clear from that, nor do I
necessarily
understand it. But certainly gcc's existing nested functions don't work this
way.
I understand, again, there are major tradeoffs either way. Ours is not
monotonically
better than gcc's.
Ah, I guess the new code is to load the static link following the -1.
A C-generating front end has other advantages:
I know what is well formed C.
I don't know what is well formed gcc/tree or gcc/gimple.
The various problems we have with the optimizer -- because our trees are
poorly formed -- would go away.
We wouldn't have to twiddle various optimizations off.
This is sort of "magic/special" -- I just happen to know far more about C
than gcc internals.
> (and there is also LLVM which could perhaps interest you).
Yeah, people have asked about using it. But nobody puts any work into
it from our side (we have precious few people doing anything!).
We aren't supposed to discuss it here. :)
And it has the same disadvantage vs. C/C++ that gcc/tree/gimple has -- I know
what is valid C/C++,
whereas LLVM is another big unknown to investigate. And it hits fewer targets.
Granted, both mainline gcc and LLVM hit plenty targets.
I do dream of having portability on par with: printf("hello world\n"); without
doing much porting myself/ourselves, and have access to wierd systems such as
VMS. :)
> future gimple front-end
Interesting. But again similar problems.
Given my knowledge, generating C/C++ easier than anything else.
Also have to wait until these versions of gcc are widespread.
Look at Apple and OpenBSD for how older gcc remains in use.
Anyway, knowing the garbage collector isn't compacting is good.
Thanks,
- Jay
----------------------------------------
> Date: Wed, 3 Nov 2010 10:23:14 +0100
> From: basile@
> To: jay.kr...@u
> CC: gcc@
> Subject: Re: is gcc garbage collector compacting?
>
[snip]
