Re: Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type)

[Philippe Mathieu-Daudé]

On 9/15/21 9:42 AM, Thomas Huth wrote:
> On 14/09/2021 17.22, Richard Henderson wrote:
>> On 9/14/21 5:26 AM, Peter Maydell wrote:
>>> (2) RAM blocks should have a length that fits inside a
>>>      signed 32-bit type on 32-bit hosts (at least I assume this
>>>      is where the 2047MB limit is coming from; in theory this ought
>>>      to be improveable but auditing the code for mishandling of
>>>      RAMblock sizes to ensure we weren't accidentally stuffing
>>>      their size into a signed 'long' somewhere would be kind
>>>      of painful)
>>
>> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit
>> while pointers are 64-bit, how close do we think we are to this being
>> fixed already?
>>
>>> Even if we did fix (2) we'd need to compromise on (3)
>>> sometimes still -- if a board has 4GB of RAM that's
>>> not going to fit in 32 bits regardless. But we would be
>>> able to let boards with 2GB have 2GB.
>>
>> I'm not opposed to deprecating 32-bit hosts...  ;-)
> 
> I think we should consider this again, indeed. Plain 32-bit CPUs are
> quite seldom these days, aren't they? And I think we urgently need to
> decrease the amount of things that we have to test and maintain in our
> CI and developer branches... So is there still a really really
> compelling reason to keep 32-bit host support alive?
> Could we maybe also decrease the amount of targets, i.e. merge
> qemu-system-x86_64 and qemu-system-i386, merge qemu-system-ppc64 and
> qemu-system-ppc, etc. where it makes sense (i.e. where one of the
> binaries is a superset of the other)?

Not directly related, but orthogonal to this, now than Richard got his
memory API series addressing endian issues merged, I'm slowly (in my
free time) trying to unify dual-endian machines. For user-emulation
it is a bit tricker so I'll look at it once sysemu is working. This
won't reduce the testing time, but the build time.