Deorbiting i386

[Maxim Sobolev]

That again is very subjective view, David. Sorry. Arm32 is kinda kind of
the hill these days in the low-power/low cost space, but arm as a company
is much more interested it seems in going into server / mobile device space
rather than solidifying it's current de-facto kingdom. Those platforms
based on their IP are very short lived and tightly coupled to a particular
vendor with zillions busses, various kinds of weird quirks,
vendor-maintained bootloaders etc. On the other hand, Intel is quickly
closing the gap. If you've seen any of the atom bay trail systems in action
you may understand what I mean. You get full blown x64 system with four
cores and it takes only 2W of power. This is roughly equivalent of ARM8
system with a single core @ only 900MHz.

So my prediction is in the 32-bit land arm will fade out as a platform and
be replaced with RiscV in matter of few years  and i386 will probably
continue to be the platform of choice for many if Intel/Amd play that card
right.

-Max

On Fri, May 25, 2018, 12:27 AM David Chisnall <theraven at freebsd.org> wrote:

> On 25 May 2018, at 05:27, Maxim Sobolev <sobomax at freebsd.org> wrote:
> >
> > The idea looks very inmature and short-sighted to me. i386 is here to
> stay not as a server/desktop platform but as an embedded/low power/low cost
> platform for at least 5-10 years to come. There are plenty of applications
> in the world that don't need > 3gb of memory space and have no use for
> extra bits (and extra silicon) to function.
>
> This argument seems very odd to me.  If you are targeting the embedded
> space, it is far easier to build a low-power chip that targets the x86-64
> ISA than the x86-32 ISA.  You can move all of the 80-bit floating point
> stuff into microcode.  You can put anything using pair-of-32-bit-register
> 64-bit operations into slow microcode.  You can skimp on store forwarding
> for stack addresses.  You actually need fewer rename registers (one of the
> biggest consumers of power), because x86-64 code needs to do less register
> juggling to fit in the architectural register space.  All of these things
> are big consumers of power and area and are far less necessary when running
> code compiled for x86-64.  You can also do tricks like the one that Intel
> did on the early Atoms, where the SSE ALUs are actually only 64 bits wide
> and the 128-bit ops are cracked into pairs of 64-bit micro-ops.
>
> As to ‘not needing more than 3GB of memory space’, that’s what the x32 ABI
> is for.  This lets you get all of the advantages of the x86-64 ISA (of
> which there are very many, in comparison to x86-32), without needing 64-bit
> pointers.  You get the instruction density of x86-64 combined with the data
> density of x86-32.  This is what Intel and Centaur have been pushing in the
> embedded space for several years.
>
> You do pay a slight hardware cost from supporting a 48-bit virtual address
> space, though with superpages that’s negligible and the hardware targeted
> at these applications often doesn’t support more than a 32-bit virtual
> address space.
>
> And this completely ignores the fact that Intel has almost no presence in
> the low-end embedded space.  AArch32 is vastly more important there and if
> we dropped x86-32 and shifted that effort to AArch32 then I think we’d see
> a lot more adoption.
>
> David
>