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 |
|
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. 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 |
|||
22 May 2023, 16:37 |
|
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. |
|||
22 May 2023, 20:44 |
|
revolution 22 May 2023, 21:07
Tomasz Grysztar wrote:
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. |
|||
22 May 2023, 21:07 |
|
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? 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. |
|||
22 May 2023, 21:11 |
|
bitRAKE 22 May 2023, 22:02
Tomasz Grysztar wrote: Isn't that what doomed the IA64? (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 |
|||
22 May 2023, 22:02 |
|
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. |
|||
22 May 2023, 22:28 |
|
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. 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 |
|||
23 May 2023, 01:29 |
|
sylware 23 May 2023, 09:17
Should it be called RISC-V?
mmmmmh... |
|||
23 May 2023, 09:17 |
|
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. |
|||
23 May 2023, 17:02 |
|
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. |
|||
24 May 2023, 06:37 |
|
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. |
|||
24 May 2023, 10:08 |
|
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 will be sad if Intel abandon 16 bit and 8 bit registers.. Quote:
Agree, ex. for big data lists - and even 3 bits, 7 bits as unit. For small data it destroys simplicity to access... |
|||
24 May 2023, 11:37 |
|
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... |
|||
24 May 2023, 13:40 |
|
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. Intel wrote: The 32-bit submode of Intel64 (compatibility mode) still exists. |
|||
24 May 2023, 16:18 |
|
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? 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? |
|||
13 Jun 2023, 16:53 |
|
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.
|
|||
13 Jun 2023, 18:01 |
|
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 _________________ - carpe noctem |
|||
13 Jun 2023, 18:13 |
|
bitRAKE 13 Jun 2023, 19:37
f0dder wrote: Binary compatibility seems to be a very big part of x86's raison d'être. f0dder wrote: wouldn't all the years of fine-tuning optimization based on architectural knowledge requires the performance characteristics to stay largely the same? 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 |
|||
13 Jun 2023, 19:37 |
|
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, .. |
|||
13 Jun 2023, 20:40 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.