Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [040625 00:27]:
On the fun side it would be extremely interesting is if you could get enough memory working to start paging and we could go into 64bit mode :) That is likely tempting fate too much.....
Ack! With all C code compiled by gcc this sounds like a reasonable goal. But will any payloads work with this?
Besides the kernel? For the payloads it does not matter. Having an ELF loader that does both 32bit and 64bit is not hard, and the code already exists in etherboot. One of the advantages of LinuxBIOS is that we don't have to run in the same processor mode as our payloads. We can switch processor word size or endianness and things should continue to work.
Even with romcc an x86-64 port would not be hard. There are just some interesting complications in using a minimal 4K page table that I have been avoiding. Thinking about it though the extra programmer visible registers might just make it worth it, especially combined with non-inlining.
One of these days I must take the time to generate a 64bit ELF executable from an Opteron kernel.
Eric, What is the "effective" or "equalvalent" stack size of ROMCC ? Is 448 bytes of stack adquant for ROMCC "linted" code in general ?
8 (gpr) + 8 (mmx) + 8 (sse) registers each 4 bytes long = 96 bytes. Looking at the hdama configuration my max inline depth is 14 procedures so that likely totals to another 14 *4 = 56 bytes in return addresses. So 448 bytes would be a small improvement.
With current CVS the code shrinks from about 90k object size to 10k.
??? I don't know where the 90k comes from. But the code compiled with romcc should likely fall into the 10k real without inlining. Currently it is about 30k-40k.
My basic objection is that I have been down the cache as ram path once, and decided there was less maintenance in doing romcc. After writing romcc I still feel that way. Not having to worry about a BIOS breaking because of a new processor and is a relief.
This is actually not bad for a small improvement. I have not tried major hand tuning with romcc's anti-inline tags yet.
In theory it should be similar in code size. In practice things aren't quite usable yet.
Eric