is_cpu_pre_c0()

[YhLu]

Can we change is_cpu_pre_c0() to global macro define

I think most K8 is C0 after.

And I can not include debug info  (MAX...._LOGLEVEL=8). The linuxbis image
is more than 65536.

Regards

YH

YhLu  writes:
> Can we change is_cpu_pre_c0() to global macro define
>
> I think most K8 is C0 after.

B3 stepping CPUs shipped in production and Ron Minnich has a large
cluster of them.  Anything earlier than B3 we can safely ignore.

I guess I don't see a problem with that.
> And I can not include debug info  (MAX...._LOGLEVEL=8). The linuxbis image
> is more than 65536.

That is a major challenge.  I have a back burner project to make romcc not
inline all function calls.  But until I do that I don't know of a good
way to reduce the code size.

Eric

[ron minnich]

On 24 Mar 2004, Eric W. Biederman wrote:
> That is a major challenge.  I have a back burner project to make romcc
> not inline all function calls.  But until I do that I don't know of a
> good way to reduce the code size.

actually there is an easy way I tested way back that worked out ok.

You put the linuxbios_c payload BEFORE the auto.c-generated code. That
really opens up the space. Requires some .lds hacking. I forget why I
never committed it -- might have been an issue with mapping the ROM space. 
It may have been because we did not have the new config tool and it was 
too much work.

ron

ron minnich  writes:
> On 24 Mar 2004, Eric W. Biederman wrote:
> > That is a major challenge.  I have a back burner project to make romcc
> > not inline all function calls.  But until I do that I don't know of a
> > good way to reduce the code size.
>
> actually there is an easy way I tested way back that worked out ok.
>
> You put the linuxbios_c payload BEFORE the auto.c-generated code. That
> really opens up the space. Requires some .lds hacking. I forget why I
> never committed it -- might have been an issue with mapping the ROM space. 
> It may have been because we did not have the new config tool and it was 
> too much work.

There is an issue with mapping ROM space, which means at least the code
to open that up needs to be within 64K or so.

Beyond that there is the piece that with if LinuxBIOS gets to big we can't
stuff a kernel in there.  And until we have exhausted all of our options
to shrink it we should not give LinuxBIOS too much license to grow.

Size will always be an important consideration for LinuxBIOS.

Currently code generated by romcc is a factor of 3 larger than hand
generated assembly.  If can get a correct implementation that does
not inline everything we should see a significant reduction in code
size.

I have incorrect implementations that show a lot of promise.  Hopefully
I can find the time to build a correct version.

My rough numbers suggest that if we can keep LinuxBIOS to 64KB.  We can
squeeze a kernel in there with a 512KByte flash chip.  If we can't using
a kernel is pushed out farther in time.

Eric