flat assembler
Message board for the users of flat assembler.

Index > Main > Intel Proposes 64-bit Mode-Only Solution (x86S)

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
bitRAKE



Joined: 21 Jul 2003
Posts: 3962
Location: vpcmipstrm
bitRAKE 22 May 2023, 16:37
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
Intel wrote:
This whitepaper details the architectural enhancements and modifications that Intel is currently investigating for a 64-bit mode-only architecture referred to as x86S (for simplification). Intel is publishing this paper to solicit feedback from the ecosystem while exploring the benefits of extending the ISA transition to a 64-bit mode-only solution.
(direct link to paper)

I'm a radical - if they are going to rework the architecture, they aren't going far enough, imho. Introducing a bunch of #UD just to truncate legacy is a waste of silicon - just redefine the specification and don't pretend compatibility. Push all legacy compatible to a VM mode.

How many times have we been through this compatibility game? It's a complete illusion in almost every case. Just take the painful discontinuity and move on. Half-assed compatibility in hardware isn't flexible and just creates more problems.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
Post 22 May 2023, 16:37
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 919
Location: Russia
macomics 22 May 2023, 17:24
I've been expecting something like this for a long time. It's time to recycle this prefabricated hodgepodge of extensions into a modern processor with a new architecture.

That's just that they've taken up their compatibility fetish again. We need to put everything together from scratch, and not make another homunculus.
Post 22 May 2023, 17:24
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8346
Location: Kraków, Poland
Tomasz Grysztar 22 May 2023, 20:44
Ever since I first heard about these plans I've been wondering what the initial state of page tables is going to be after the cold start of CPU. Is it going to pre-fill some minimal necessary structures by itself? Or are the initial page tables going to be a part of booted image? I did not find any answer to that in the published documents.

bitRAKE wrote:
I'm a radical - if they are going to rework the architecture, they aren't going far enough, imho.
Isn't that what doomed the IA64?
Post 22 May 2023, 20:44
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20180
Location: In your JS exploiting you and your system
revolution 22 May 2023, 21:07
Tomasz Grysztar wrote:
bitRAKE wrote:
I'm a radical - if they are going to rework the architecture, they aren't going far enough, imho.
Isn't that what doomed the IA64?
It was the expectation that compliers would become better that killed it.

Intel pushed all the optimisation onto the compilers. But it turns out that writing compilers is too hard for humans to do, so they ended up with crap code that performed badly. And you also needed to recompile for each new design to make use of all the units inside the chip.

The same will happen for the Mill CPU IMO. You need some amazingly awesome compiler to make good use of it. But no such compiler exists, or is likely to ever exist.
Post 22 May 2023, 21:07
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 919
Location: Russia
macomics 22 May 2023, 21:11
Tomasz Grysztar wrote:
Is it going to pre-fill some minimal necessary structures by itself? Or are the initial page tables going to be a part of booted image?
What prevents from simply loading the initial values into the TLB (as RIP = 0xFFFFFFFFFFFFFFF0) before the BIOS/EFI fills in the values of the corresponding tables. The main thing is to provide initial access to the pages of ROM address projection to memory.

A single TLB can contain information about a memory page up to 1 GB. Even if they are stingy and encode 2 MB there, then this is quite enough to ensure the start of the initial ROM and fill the corresponding memory tables from it.
Post 22 May 2023, 21:11
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3962
Location: vpcmipstrm
bitRAKE 22 May 2023, 22:02
Tomasz Grysztar wrote:
Isn't that what doomed the IA64?
Just to expand on what was already said: at the top end IA64 was a VLIW arch. The problem with all RISC-type designs that aim for performance is poor optimization in fixed granularity and dynamic code generation - which means that performance always requires reordering after decode regardless of instruction width. The only benefit to fixed instruction width is low power - optimization is not so aggressive, imho.

(GPU is different animal - RISC-like design works well there. More like a freight train than a sports car. Technically, it's low-power from the watt/thread perspective.)

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup


Last edited by bitRAKE on 25 May 2023, 13:14; edited 2 times in total
Post 22 May 2023, 22:02
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20180
Location: In your JS exploiting you and your system
revolution 22 May 2023, 22:28
Yes, I omitted to mention that workloads can't be statically optimised by the complier, no matter how fantastic the compiler is. It needs to be in the CPU to properly detect all the gaps in the stream and fill them with other work. But this get us off topic.

If x86S is to be a thing then to keep performance high AMD/Intel will have to keep all the OOO complexity intact. It is really only the decoder stage that gets simplified. And if the compilers can remain mostly as they are then it could be a win. It is unclear to me how much space/power the current decoders use but perhaps it is significant amount.

For page tables the existing 1:1 mapping used for real node can be used. Nothing needs to be added to fill any tables. If paging is not enabled then the address-in is passed to address-out unmodified.
Post 22 May 2023, 22:28
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3962
Location: vpcmipstrm
bitRAKE 23 May 2023, 01:29
revolution wrote:
Yes, I omitted to mention that workloads can't be statically optimised by the complier, no matter how fantastic the compiler is. It needs to be in the CPU to properly detect all the gaps in the stream and fill them with other work. But this get us off topic.
Just to expand the topic:

Can we take a moment to marvel at what nature accomplished. DNA is essentially a bi-level fixed width instruction set that produces variable length programs. At the primary level, the DNA sequence codes for amino acids via codons—groups of three nucleotides. But there's also a higher level of control: regulatory elements in the DNA sequence can influence when and where a gene is expressed, effectively acting as control flow instructions.

Moreover, one gene can give rise to multiple proteins through a process called alternative splicing, where different segments of an RNA transcript are included or excluded from the final protein product.

Proteins, in turn, perform a variety of functions, from catalyzing biochemical reactions (enzymes) to acting as structural elements, messengers, and transporters.

Completely different from how we think of software.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
Post 23 May 2023, 01:29
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 423
Location: Marseille/France
sylware 23 May 2023, 09:17
Should it be called RISC-V?


mmmmmh...
Post 23 May 2023, 09:17
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 2465
Furs 23 May 2023, 17:02
There's 0 reason to not have compatibility for applications, in that case might as well just go with a new arch, and we know how that ends up. (ARM does not count because it did not take an already established sector, it just filled a new one)

This looks like it will just drop support for all non-64-bit OSes, which is a bit of a shame, but understandable. 32-bit mode in 64-bit will still exist, for apps for example. Unsure about 16-bit mode (not real mode).

RIP FreeDOS though.
Post 23 May 2023, 17:02
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20180
Location: In your JS exploiting you and your system
revolution 24 May 2023, 06:37
There is still a need for 8, 16, 32, and 64-bit values. You can't go to 100% 64-bit values only. It would be very inefficient.

I think it is wrong to call it 32-bit "mode" if you just mean 32-bit registers and values. The same for 16-bit "mode". The registers can still be accessed as the lower (8/16/32)-bits in 64-bit mode, so EAX, AX, and AL would still have valid encodings.
Post 24 May 2023, 06:37
View user's profile Send private message Visit poster's website Reply with quote
MHajduk



Joined: 30 Mar 2006
Posts: 6115
Location: Poland
MHajduk 24 May 2023, 10:08
revolution wrote:
There is still a need for 8, 16, 32, and 64-bit values. You can't go to 100% 64-bit values only. It would be very inefficient.

I think it is wrong to call it 32-bit "mode" if you just mean 32-bit registers and values. The same for 16-bit "mode". The registers can still be accessed as the lower (8/16/32)-bits in 64-bit mode, so EAX, AX, and AL would still have valid encodings.
Sometimes it would be convenient to have a possibility to define own base units of information. There are situations when 8-bit byte seems too big for some applications.
Post 24 May 2023, 10:08
View user's profile Send private message Visit poster's website Reply with quote
macgub



Joined: 11 Jan 2006
Posts: 345
Location: Poland
macgub 24 May 2023, 11:37
revolution wrote:
There is still a need for 8, 16, 32, and 64-bit values. You can't go to 100% 64-bit values only. It would be very inefficient.

I think it is wrong to call it 32-bit "mode" if you just mean 32-bit registers and values. The same for 16-bit "mode". The registers can still be accessed as the lower (8/16/32)-bits in 64-bit mode, so EAX, AX, and AL would still have valid encodings.

I will be sad if Intel abandon 16 bit and 8 bit registers..
Quote:

Sometimes it would be convenient to have a possibility to define own base units of information. There are situations when 8-bit byte seems too big for some applications.


Agree, ex. for big data lists - and even 3 bits, 7 bits as unit. For small data it destroys simplicity to access...
Post 24 May 2023, 11:37
View user's profile Send private message Visit poster's website Reply with quote
MHajduk



Joined: 30 Mar 2006
Posts: 6115
Location: Poland
MHajduk 24 May 2023, 13:40
macgub wrote:
Agree, ex. for big data lists - and even 3 bits, 7 bits as unit. For small data it destroys simplicity to access...
Yes, that's what I exactly meant. Smaller chunks of data have to be packed (if we want compactness) and, consequently, their boundaries may appear on different bits of consecutive bytes. Unpacking such data may be then a cumbersome task. Smile
Post 24 May 2023, 13:40
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8346
Location: Kraków, Poland
Tomasz Grysztar 24 May 2023, 16:18
revolution wrote:
I think it is wrong to call it 32-bit "mode" if you just mean 32-bit registers and values. The same for 16-bit "mode". The registers can still be accessed as the lower (8/16/32)-bits in 64-bit mode, so EAX, AX, and AL would still have valid encodings.
As stated in the document:
Intel wrote:
The 32-bit submode of Intel64 (compatibility mode) still exists.
So it would still be possible to have USE32 segments. The compatibility mode is a 32-bit code running within long mode, not to be confused with legacy modes, which are all modes outside of long mode, and which are going to be removed here.
Post 24 May 2023, 16:18
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 13 Jun 2023, 16:53
I wonder how much will be gained by this trimming – it still keeps a helluvalot of the complexity of the x86 platform. We still need (most of) the x86 decoder, and I don't see how e.g. the actual execution engine can be improved by cutting the cruft.

There's a chunk of microcode that can be tossed out, probably also a bit of dedicated circuitry - but does it allow for any architectural improvements to the remanining stuff? And what percentage of transistors will be saved - does it give any noticable die space that can be used for e.g. a bit more L1 cache?

It seems like an OK idea to cut unused parts, but I don't see it leading to big gains - what am I missing? Smile

As for coming up with something totally new, I'm not sure we need Yet Another Architecture. As much as I hate to admit it, Apple is doing pretty damn well with their Apple Silicon, and perhaps one day RISC-V might also be worth looking at. But a totally new architecture replacing the diversity of what x86 does well now, from gaming to high-end desktops to servers? With all the years of improvement to the frankenstein architecture, all the compiler optimizations? Would we trust Intel to have learned from the Itanium mistakes? Wink
Post 13 Jun 2023, 16:53
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3962
Location: vpcmipstrm
bitRAKE 13 Jun 2023, 18:01
x86S will be new - there are many degrees of new before we get to totally new. The ISA could be largely the same at the mnemonic level and completely different at the binary level. The compiler infrastructure is sufficiently advanced as to make this result in very little change. Of course, binary incompatibility would come with it's own headache, and I seriously doubt Intel is ramping up to such a big change - they'll play it safe.
Post 13 Jun 2023, 18:01
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 13 Jun 2023, 18:13
bitRAKE wrote:
The ISA could be largely the same at the mnemonic level and completely different at the binary level.

Would that be worth it *at all*, though? Yes, Intel and AMD have been doing some pretty interesting things, but if you look at the level of performance Apple are getting at a much lower Watt/perf... binary compatibility seems to be a very big part of x86's raison d'être.

bitRAKE wrote:
The compiler infrastructure is sufficiently advanced as to make this result in very little change.

Spitting out new machine code for the same mnemonics, sure, pretty minor change. But wouldn't all the years of fine-tuning optimization based on architectural knowledge requires the performance characteristics to stay largely the same?

If the mnemonics stay the same and the overall performance characteristics need to be similar, what have we gained – somewhat simpler front-end decoding logic?

I'm probably missing something, or misunderstanding you Smile

_________________
Image - carpe noctem
Post 13 Jun 2023, 18:13
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3962
Location: vpcmipstrm
bitRAKE 13 Jun 2023, 19:37
f0dder wrote:
Binary compatibility seems to be a very big part of x86's raison d'être.
Really? UEFI boots into 64-bit. 8-bit stuff had needed an emulator for a long time. Several Linux distro are carving out 32-bit. The landscape of processor extensions is a mess. I think the modern tooling compensates for a very complex environment that has been created.
f0dder wrote:
wouldn't all the years of fine-tuning optimization based on architectural knowledge requires the performance characteristics to stay largely the same?
This is less true than it was in the past as well. Modern optimization has the fine-tuning automated in a way that can pivot with diverse CPU architectures.

I don't know if I should agree with you yet? You're making all my points for me. You don't think Intel feels pressure from these other market segments? You don't think x86 needs to look for a pivot given how flexible the modern tooling is? 10/20 years from now - what? x86 is just dead, or largely the same? I think there is an opportunity to pivot for a different future for x86 - an expansive open migration path.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
Post 13 Jun 2023, 19:37
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20180
Location: In your JS exploiting you and your system
revolution 13 Jun 2023, 20:40
f0dder wrote:
As for coming up with something totally new, I'm not sure we need Yet Another Architecture. As much as I hate to admit it, Apple is doing pretty damn well with their Apple Silicon, ..
Yes they are. And a large part of that is the ISA. The decoder logic for ARM is an order of magnitude.simpler. And RISC-V takes it another order further. I guess Intel are quite jealous of that. Simpler ISA encodings simplify so many design choices.
Post 13 Jun 2023, 20:40
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.