why is firmware 32 bit as opposed to 64 bit

[John de la Garza]

I understand that the calling functions in 32 bit C uses the stack and
this is why coreboot needs to use cache as RAM.  Doesn't 64 bit C use
registers to pass arguments to functions?  If this is the case why not
run in 64 bit mode?

Also, even if cache as RAM is used and a stack is available, why not just
build a 64 bit binary?  What are the advantages to using a 32 bit binary?

[Patrick Georgi]

Am 10.08.2014 um 21:06 schrieb John de la Garza:
> Doesn't 64 bit C use registers to pass arguments to functions?  If 
> this is the case why not run in 64 bit mode?
> Even in 64bit mode you have to store state somewhere (that is, on the
> stack) before you have free registers to call new functions.

Patrick

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 10.08.2014 21:06, John de la Garza wrote:
> I understand that the calling functions in 32 bit C uses the stack and
> this is why coreboot needs to use cache as RAM.  Doesn't 64 bit C use
> registers to pass arguments to functions?  If this is the case why not
> run in 64 bit mode?
>
> Also, even if cache as RAM is used and a stack is available, why not just
> build a 64 bit binary?  What are the advantages to using a 32 bit binary?

long mode (64-bit) needs paging table in RAM. So no 64-bit for preram
binary. For rest it's theoretically possible but it's too much hassle
for no benefit.

[ron minnich]

One of the reasons I"m working to implement paging for 32-bit mode is
for our eventual change to 64-bit mode for coreboot. It's gone on the
back  burner for a bit as I'm doing a few other coreboot things first.

I'd love to have the help, if you have time.

ron

On Sun, Aug 10, 2014 at 1:02 PM, Vladimir 'φ-coder/phcoder' Serbinenko
<[e-mail]> wrote:
> On 10.08.2014 21:06, John de la Garza wrote:
> > I understand that the calling functions in 32 bit C uses the stack and
> > this is why coreboot needs to use cache as RAM.  Doesn't 64 bit C use
> > registers to pass arguments to functions?  If this is the case why not
> > run in 64 bit mode?
> >
> > Also, even if cache as RAM is used and a stack is available, why not just
> > build a 64 bit binary?  What are the advantages to using a 32 bit binary?
>
> long mode (64-bit) needs paging table in RAM. So no 64-bit for preram
> binary. For rest it's theoretically possible but it's too much hassle
> for no benefit.

[Scott Duplichan]

Vladimir 'φ-coder/phcoder' Serbinenko [mailto:[e-mail]] wrote"


]On 10.08.2014 21:06, John de la Garza wrote:
]> I understand that the calling functions in 32 bit C uses the stack and
]> this is why coreboot needs to use cache as RAM.  Doesn't 64 bit C use
]> registers to pass arguments to functions?  If this is the case why not
]> run in 64 bit mode?
]> 
]> Also, even if cache as RAM is used and a stack is available, why not just
]> build a 64 bit binary?  What are the advantages to using a 32 bit binary?
]> 
]>
]long mode (64-bit) needs paging table in RAM. So no 64-bit for preram
]binary. For rest it's theoretically possible but it's too much hassle
]for no benefit.

The page table requirement is certainly a negative for x64 mode.
Another is code size. Code grows by several percent when compiled
for x64 mode. Use of x32 ABI could reduce the code size penalty,
but page tables are still required.

Most UEFI uses 32-bit mode until RAM is ready, then x64 mode
after that. Unlike coreboot, UEFI doesn't prioritize code size
minimization. Minimum code size is needed for fast boot, because
the code must be read from the relatively slow flash chip before
it can execute. Coreboot does prioritize fast boot. Switching
coreboot to x64 mode would result in a measurable boot time
degradation I believe.

One advantage of x64 mode is easy use of DRAM structures larger
then 4GB. Boot firmware is unlikely to benefit from this. Another
benefit of x64 mode is use of additional registers. The additional
registers can lead to faster code. But boot firmware is usually I/O
bound, so it is unlikely the extra registers could lead to a
measurable boot time reduction.

Thanks,
Scott

[Marc Jones]

Nice answer, Scott.

You pointed out everything I was going to say. I think this is
something we should put on the wiki in a FAQ. A 64bit ramstage has
questionable value, but a 64bit payload might be useful.

Marc


On Sun, Aug 10, 2014 at 4:20 PM, Scott Duplichan <[e-mail]> wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko [mailto:[e-mail]] wrote"
>
> ]On 10.08.2014 21:06, John de la Garza wrote:
> ]> I understand that the calling functions in 32 bit C uses the stack and
> ]> this is why coreboot needs to use cache as RAM.  Doesn't 64 bit C use
> ]> registers to pass arguments to functions?  If this is the case why not
> ]> run in 64 bit mode?
> ]>
> ]> Also, even if cache as RAM is used and a stack is available, why not just
> ]> build a 64 bit binary?  What are the advantages to using a 32 bit binary?
> ]>
> ]>
> ]long mode (64-bit) needs paging table in RAM. So no 64-bit for preram
> ]binary. For rest it's theoretically possible but it's too much hassle
> ]for no benefit.
>
> The page table requirement is certainly a negative for x64 mode.
> Another is code size. Code grows by several percent when compiled
> for x64 mode. Use of x32 ABI could reduce the code size penalty,
> but page tables are still required.
>
> Most UEFI uses 32-bit mode until RAM is ready, then x64 mode
> after that. Unlike coreboot, UEFI doesn't prioritize code size
> minimization. Minimum code size is needed for fast boot, because
> the code must be read from the relatively slow flash chip before
> it can execute. Coreboot does prioritize fast boot. Switching
> coreboot to x64 mode would result in a measurable boot time
> degradation I believe.
>
> One advantage of x64 mode is easy use of DRAM structures larger
> then 4GB. Boot firmware is unlikely to benefit from this. Another
> benefit of x64 mode is use of additional registers. The additional
> registers can lead to faster code. But boot firmware is usually I/O
> bound, so it is unlikely the extra registers could lead to a
> measurable boot time reduction.
>
> Thanks,
> Scott