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?
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
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.
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 phcoder@gmail.com 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.
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Vladimir 'φ-coder/phcoder' Serbinenko [mailto:phcoder@gmail.com] 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
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 scott@notabs.org wrote:
Vladimir 'φ-coder/phcoder' Serbinenko [mailto:phcoder@gmail.com] 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
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
John de la Garza -
Marc Jones -
Patrick Georgi -
ron minnich -
Scott Duplichan -
Vladimir 'φ-coder/phcoder' Serbinenko