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

[Thomas Huth]

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)?

 Thomas