[M3devel] gcc 4.5.0?

[Tony Hosking]

Yes, we do make use of some of gcc's static chain machinery.  We just avoid the need for the trampolines that gcc uses because we need a reified static chain that is otherwise computed in the trampoline on the way to calling a nested procedure.

On 20 May 2010, at 10:01, Jay K wrote:

> 
> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
> Don't any of the other languages need it already?
> Ada? Pascal? Maybe the nested C function support?
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 20 May 2010 09:54:14 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> 
>> 
>> On 20 May 2010, at 09:21, Jay K wrote:
>> 
>>> 
>>> eh, ok, I'll try that then.
>>> 
>>> 
>>> Have you noticed what I did for OpenBSD?
>>> Perhaps easier to just commit those diffs?
>>> In order to facilitate merging?
>>> Tedious either way of course.
>>> 
>>> 
>>> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>>> OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
>>> Largely they aren't relevant, like to c-*.c.
>>> Largely they are trivial. Just configure/makefile snippets.
>>> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
>>> We apply them during our build, in m3makefile.
>>> 
>>> 
>>> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
>>> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
>>> And commit with minimal testing instead of a big matrix.
>>> 
>>> 
>>> But it bloats the source tree a lot.
>>> 
>>> 
>>> I'd also like to somehow reduce how often gmp and mpfr are built.
>>> They are a huge fraction of the time.
>>> And 4.5.0 adds another similar library, mpc.
>>> "c" for complex numbers..more stuff we don't use...
>>> 
>>> 
>>> It seems our main changes are:
>>> introducing of static chain for nested procedures
>>> Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>>> Or Pascal? I mean..do we have to add our own?
>> 
>> Yes, we need the support for extracting the static chain for passing with procedure arguments. Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain). i.e., they are "static" closures.
>> 
>>> small hacks to inhibit optimisation
>> 
>> It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.
>> 
>>> the little makefile machinery
>>> 
>>> 
>>> Also, have you noticed that 4.5.0 has a "plugin" interface?
>> 
>> Yes, I'd heard about that.
>> 
>>> Perhaps we can just use that, and just distribute a small .so file.
>> 
>> That would be *very* cool.
>> 
>>> At least once 4.5.0 is in wide use.
>> 
>> Right.
>> 
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Thu, 20 May 2010 09:10:03 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>> 
>>>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>>>> 
>>>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>>>> 
>>>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>>>> 
>>>> On 20 May 2010, at 07:50, Jay K wrote:
>>>> 
>>>>> 
>>>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>>>> 
>>>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>>>> 
>>>>> Merge it to the "gcc" branch?
>>>>> 
>>>>> And then to head?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> I mean, you know..there are all the directions out there for managing
>>>>> external trees, but I think the main missing detail is what
>>>>> branches/tag names to use to match previous history, and it isn't
>>>>> immediately clear to me..from, um, reading the history (which imho is
>>>>> yet another indictment of CVS -- I can't figure out what happened).
>>>>> 
>>>>> 
>>>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>>>> But I haven't ever updated it.
>>>>> e.g. cvsup.
>>>>> 
>>>>> 
>>>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>>>> The diffs are quite small.
>>>>> But I know that's not considered the right way.
>>>>> 
>>>>> 
>>>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>