Using Cache As Ram for K8
Eric W. Biederman
ebiederman at lnxi.com
Thu Jun 24 19:05:00 CEST 2004
Stefan Reinauer <stepan at openbios.org> writes:
> * Eric W. Biederman <ebiederman at 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.
More information about the coreboot