Ram initialization and small c.

[Eric W. Biederman]

Steve Gehlbach <steve at nexpath.com> writes:

> Eric W. Biederman wrote:
> 
> > Steve for a feel of my worries try compiling that code with gcc-3.3.  If
> > what I saw earlier today is right it won't work because someone has decided
> > that aggressive inlining is bad thing...
> >
> 
> Hmm... I assume you mean gcc-3.2.2 unless you have a pre-release.  

I don't currently have a pre release but that is what I was thinking about.
But 3.3 is scheduled to release in the next couple of weeks.  And one
of the issues that was being vigorously discussed on the gcc list
was how to handle the fact that 3.3 does not inline nearly as much as 3.2
and there was not currently a way to get it to inline more than it thought
was reasonable.
was 

> on a RH machine, it seems to work on my code, although I had to delete a couple
> of asm's and fiddle with raminit.c: went back to "register int i asm ("ecx");".
> Otherwise gcc3.2 was more efficient (-181 lines), and it uses the %ebp
> differently.  As a result, checking for "push" or "esp" is not effective to
> determine spill cases, you have to look for %ebp which it does tmp storage with
> mov's.

The requirements of these small tweaks when building are why I am convinced
that in the long run we need actual compiler support.  Either in gcc or
in one we write ourselves.  For now we have an easier way to generate the
assembly code.

> Interesting that gcc3.2 seems to ignore the -fomit-frame-pointer since there is
> a "leave" at the end.  Not sure why.
> 
> Note the reason for the push of the %ebp in gcc2.95 is that 2.95 uses it for
> temp storage (hadn't noticed this before) if you set -fomit-frame-pointer, and
> so it push/pops it on entry and leaving.

That makes sense.

Eric