Intel Publishes "X86-S" Specification For 64-bit Only Architecture

[Wat]

There's a trick to doing that using two 64-bit floats. Effectively you approximate with one float and use the other for storing the error.

Ironically within the past 10 years there's been more demand for lesser precision floating point hardware. GPUs have added 16-bit and even 8-bit float support. Mainly because they don't take up much space and you can pack a lot of them on a die. Neural networks don't need crazy high precision floats, but training LLMs requires tons of them.

128-bit floats are a nice idea, but not exactly in demand right now.

The last time I needed quad+ precision numbers, I translated an arbitrary precision library. It worked great, except it was extremely slow.

Not something I use every day, but when you need it, you need it.

 

[erek]

The last time I needed quad+ precision numbers, I translated an arbitrary precision library. It worked great, except it was extremely slow.

Not something I use every day, but when you need it, you need it.

Could you find a crafty, clever, and sophisticated way to optimize the performance analogous to the Magick Number and Fast Inverse Square Root formula and incantation? John Carmack did it

Context:

“Fast inverse square root, sometimes referred to as Fast InvSqrt() or by the hexadecimalconstant 0x5F3759DF, is an algorithm that estimates

, the reciprocal (or multiplicative inverse) of the square root of a 32-bit floating-point number

in IEEE 754 floating-point format. This operation is used in digital signal processing to normalize a vector, such as scaling it to length 1. For example, computer graphics programs use inverse square roots to compute angles of incidence and reflection for lighting and shading. Predated by similar video game algorithms, this one is best known for its implementation in 1999 in Quake III Arena, a first-person shooter video game heavily based on 3D graphics.”

 

[Lakados]

The last time I needed quad+ precision numbers, I translated an arbitrary precision library. It worked great, except it was extremely slow.

Not something I use every day, but when you need it, you need it.

There are some good and decently fast CUDA libraries for that.

 

[serpretetsky]

As of my knowledge cutoff in 2021, the cost of reading and writing DNA was still quite high, making it less suitable for general-purpose computing.

In conclusion, while it's theoretically possible to devise such an interface, there are significant practical challenges to overcome.

Ok... completely off-topic, but seriously. Erek, I knew for a long time that parts of your posts were AI generated, but like.. what are you.... completely a bot? Or you just post a lot of bot generated stuff? Explain please.

 

[staknhalo]

Ok... completely off-topic, but seriously. Erek, I knew for a long time that parts of your posts were AI generated, but like.. what are you.... completely a bot? Or you just post a lot of bot generated stuff? Explain please.

He's plugged into the Matrix

 

[Luke M]

"64 bit only" refers to OS...x86-S still runs 32-bit code. The only thing you might miss is the ability to boot up in classic BIOS mode, run MS-DOS, etc. Not an every day necessity but can be useful.

 

[Sycraft]

"64 bit only" refers to OS...x86-S still runs 32-bit code. The only thing you might miss is the ability to boot up in classic BIOS mode, run MS-DOS, etc. Not an every day necessity but can be useful.

True that should be the case as looking at their list I don't' notice a removal of compatibility mode inside long mode which is what 32-bit software runs in on a 64-bit OS. Now if they are also pulling out compatibility mode then ya, all 32-bit code would break. But so long as it is in there it should run as it does now when you have a 64-bit OS. If that keep that intact, I don't see this being a problem at all. I haven't run a non-64-bit OS for, man, probably over a decade.

 

[Red Falcon]

It already did. It came out in 1999 and was called SSE.

Unless you mean 128-bit addressing, which is dumb and uncessesary considering 64-bit addressing takes us all the way up to exabytes of addressable memory.

I think they mean 128-bit registers, which do exist but not with the x86 CPU ISA.
Outside of scientific and very specific use-cases, I don't think these are seen out in the wild very often.

Also, as schoolslave pointed out most modern CPUs use 44-bit to 48-bit memory address buses, not 64-bit.

 

[serpretetsky]

Also, as schoolslave pointed out most modern CPUs use 44-bit to 48-bit memory address buses, not 64-bit.

I think in the context of ISA it's 64 bit addressing. Either way still a valid point. For memory addressing 128bit is kind of pointless for the foreseeble future. 2^64 Bytes ought to be enough for anyone.

 

[erek]

I think they mean 128-bit registers, which do exist but not with the x86 CPU ISA.
Outside of scientific and very specific use-cases, I don't think these are seen out in the wild very often.

Also, as schoolslave pointed out most modern CPUs use 44-bit to 48-bit memory address buses, not 64-bit.

I think in the context of ISA it's 64 bit addressing. Either way still a valid point. For memory addressing 128bit is kind of pointless for the foreseeble future. 2^64 Bytes ought to be enough for anyone.

RISC-V RV128 architecture might be fully native 128bit addressable memory space

A ‘candidate’ RISC-V 128-bit ISA is proposed for an ABI that can choose to use either 64-bit or 128-bit pointers.

https://github.com/brucehoult/riscv-meta/blob/master/doc/src/rv128.md

 

[Red Falcon]

I think in the context of ISA it's 64 bit addressing. Either way still a valid point. For memory addressing 128bit is kind of pointless for the foreseeble future. 2^64 Bytes ought to be enough for anyone.

The physical memory bus address width is 44-bit, and virtual is 48-bit on modern x86 CPUs.
Motherboards can artificially set this much lower on the total RAM limit, but on the CPU that is the limit.

RISC-V RV128 architecture might be fully native 128bit addressable memory space

A ‘candidate’ RISC-V 128-bit ISA is proposed for an ABI that can choose to use either 64-bit or 128-bit pointers.

https://github.com/brucehoult/riscv-meta/blob/master/doc/src/rv128.md

Very interesting, though I doubt that would be taken advantage of on a single CPU for decades, but perhaps it would be useful for large-scale clusters or multi-node systems.

 

[serpretetsky]

The physical memory bus address width is 44-bit, and virtual is 48-bit on modern x86 CPUs.
Motherboards can artificially set this much lower on the total RAM limit, but on the CPU that is the limit.

Yes. Im getting a little confused, are you claiming these limitations are part of the ISA?

 

[Red Falcon]

Yes. Im getting a little confused, are you claiming these limitations are part of the ISA?

I think it is more just an architectural decision, and is more a designer/cost decision than it is a specific ISA limitation.
Pretty sure ARM, Power ISA, SPARC, etc. are all the same or similar in the last decade.

 

[OutOfPhase]

I think it is more just an architectural decision, and is more a designer/cost decision than it is a specific ISA limitation.
Pretty sure ARM, Power ISA, SPARC, etc. are all the same or similar in the last decade.

Correct. It is not an instruction set problem. This is just practical - there is no need to wire up and support the high order bits for an amount of memory the motherboard cannot actually support.

 

[toast0]

Correct. It is not an instruction set problem. This is just practical - there is no need to wire up and support the high order bits for an amount of memory the motherboard cannot actually support.

I think we're not too far away from 44-bit being too few for (server) addressing, that's "only" 16TB, which has to be enough for system ram and memory mapped i/o. But much more and it becomes real unweildy, real quick.

 

[OutOfPhase]

I think we're not too far away from 44-bit being too few for (server) addressing, that's "only" 16TB, which has to be enough for system ram and memory mapped i/o. But much more and it becomes real unweildy, real quick.

Oh sure. And companies making solutions for those markets will then support more lines as needed. My point was just that it is just a lot of work and validation to truly support more than anyone is reasonably interested in today, so it doesn't exist today. NOT a statement of "nobody needs more than ..."

 

[SunnyD]

"64 bit only" refers to OS...x86-S still runs 32-bit code. The only thing you might miss is the ability to boot up in classic BIOS mode, run MS-DOS, etc. Not an every day necessity but can be useful.

Not sure what your context is here, but if it's just about x86-S, cite it or bite it. X86-S is a fully 64-bit architecture. It has exactly zero legacy support for 32-bits in the ISA. Any legacy comparability would be provided through virtualization only.

The X86-S ISA does away with many of the vestiges of x86 that provide backwards compatibility and simply wouldn't be present in the physical CPU or ISA at all. So no... It wouldn't run 32-bit code directly on the CPU ever.

 

[erek]

Not sure what your context is here, but if it's just about x86-S, cite it or bite it. X86-S is a fully 64-bit architecture. It has exactly zero legacy support for 32-bits in the ISA. Any legacy comparability would be provided through virtualization only.

The X86-S ISA does away with many of the vestiges of x86 that provide backwards compatibility and simply wouldn't be present in the physical CPU or ISA at all. So no... It wouldn't run 32-bit code directly on the CPU ever.

Think it’ll fail like IA-64?

 

[Lakados]

Think it’ll fail like IA-64?

Maybe, but it's still the best-proposed counter to ARM in the data center that either AMD or Intel have proposed in the past few years.

 

[KazeoHin]

This sounds like it is 100% to create a version of X86 that AMD can't use.

 

[Wat]

Think it’ll fail like IA-64?

If it is priced like IA-64 was, yes.

 

[Luke M]

Not sure what your context is here, but if it's just about x86-S, cite it or bite it. X86-S is a fully 64-bit architecture. It has exactly zero legacy support for 32-bits in the ISA. Any legacy comparability would be provided through virtualization only.

The X86-S ISA does away with many of the vestiges of x86 that provide backwards compatibility and simply wouldn't be present in the physical CPU or ISA at all. So no... It wouldn't run 32-bit code directly on the CPU ever.

https://www.intel.com/content/dam/d...g-future-simplified-architecture/figure-2.png

64-bit mode of AMD64 supports 32-bit apps and x86-S doesn't remove this.

 

[SmokeRngs]

This sounds like it is 100% to create a version of X86 that AMD can't use.

I doubt this is the case. At the moment AMD isn't the biggest threat to Intel and in many ways AMD is necessary. Even if AMD takes marketshare away from Intel it means that marketshare is still x86 and Intel can take that back. Also, AMD can't supply enough chips to truly threaten Intel. AMD is more of a partner in this scenario.

Intel's attempt to previously move the architecture so AMD couldn't use it failed spectacularly with the Itanic. There is little chance Intel would try the same thing again especially considering AMD could pull something similar to x86-64. x86's claim to fame, longevity and market penetration is due to backwards compatibility which is one of the biggest reasons the Itanic died a swift death. To kill off backwards compatibility would likely be the death knell of x86. Virtual machines are nice but they are far from a perfect and seamless solution to the removal of backwards compatibility.

I don't doubt that Intel would like to kill off portions of x86 though I'm not convinced it would be of any substantial benefit. However, this announcement and proposal is likely a test to find out the reactions of major players. I don't think Intel did this with the Itanic and it bit them in the ass hard. It could also be a warning that this is going to happen and for software companies to prepare.

 

[SunnyD]

https://www.intel.com/content/dam/d...g-future-simplified-architecture/figure-2.png

64-bit mode of AMD64 supports 32-bit apps and x86-S doesn't remove this.

Fair enough. I stand corrected The wording in certain places implied using virtualization for even all of 32-bit support, along with the removal of certain functionality that would seem to break 32-bit user mode in general. It makes a bit more sense I suppose as 32 & 64 bit modes are flat and don't need as many hoops to jump through to transition between.