|Subject:||Re: [RFC PATCH] configure: deprecate 32 bit build hosts|
|Date:||Wed, 2 Oct 2019 23:24:29 +0200|
|User-agent:||Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0|
On 02/10/2019 17:16, Richard Henderson wrote:
On 10/2/19 2:10 AM, Daniel P. Berrangé wrote:GCC only implements int128_t for 64-bit targets.QEMU probes for that during configure and sets CONFIG_INT128 If I'm reading correctly include/qemu/int128.h then provides a fallback type based on a struct with two int64s. This has some inconvenience though as you have to use the the (inline) function calls for all the basic operands and will be less efficient when using the fallback. Presumably this is not viable for TCG ?A structure (for some ABIs) may be passed and returned by invisible reference. It's not impossible (nothing's impossible), but it adds previously unnecessary complexity to allocate that storage on the jit stack. Actually manipulating one 128-bit value consumes 4/6 of the i386 registers, which I can well imagine could wind up causing problems. Certainly manipulating two values at once is out of the question. That's less of a problem for arm and mips.
Note that all newer i386 chips (specifically 486DX and up) include at least
eight 64 bit registers and int operations in the floating point unit. Using
those to open-code 128 bit arithmetic would probably require using at least 5/8
of those, this (like any other emulation of a CPU with more total register
space) would probably require some spilling of virtual registers to some part
of RAM. 486SX and older (all the way down to the 8086) also have those, but
only if the x87 coprocessor is installed or emulated by the host OS kernel.
Later i386 models have even more features for int128 emulation in their larger
floating point units.
Anyway, all of the pain points go away if we assume 64-bit.
|[Prev in Thread]||Current Thread||[Next in Thread]|