ron minnich rminnich@lanl.gov 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