Date: Fri, 28 Apr 2023 01:44:28 +0200 From: Hans Petter Selasky <hps@selasky.org> To: 'freebsd-arch' <freebsd-arch@freebsd.org>, John Baldwin <jhb@FreeBSD.org> Subject: Re: Future of 32-bit platforms (including i386) Message-ID: <671d3bf6-b207-e7c5-5282-4df317193db6@selasky.org> In-Reply-To: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org> References: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/27/23 19:19, John Baldwin wrote: > For 13.0, i386 was demoted from Tier 1 to Tier 2. In the announcement > of this for 13.0, the project committed to an update on i386's future > around the time of 14.0. The announcement at the time suggested that > i386 would be supported less in 14.x than in 13.x. Hi, This makes me think about all the issues about the "long" type in the past, and printf() and more, being caught when compiling TARGET_ARCH=i386 . Maybe just put the following line of code somewhere central :-) _Static_assert(sizeof(long) == 8); Will there ever be some kind of hybrid CPU systems? 4 cores AMD64, 4 cores AARCH64 and some virtual QEMU CPUs all running on the same system? I mean, the arm vs intel battle is not going to end soonish. And emulating CPUs is slow and waste electricity. Why not have one computer having both kind of CPUs, and one OS, and one harddisk? And figure out a common ABI allowing seamless task switching between them? I know there are some hard differences, but can't those be ironed out? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?671d3bf6-b207-e7c5-5282-4df317193db6>