Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The x86 architecture is the weirdo, part 2

devblogs.microsoft.com

Post reply on HN
Print view View original

111–120 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#111

Post by gumby »

pm215 wrote: post #89
gumby wrote: post #38

Earlier quoted context omitted.

> CPU architectures implicitly have something I call the "architectural weirdness budget" The point of designing a new architecture is you have a point to make (generally, "doing X will lead to faster execution"). So by definition you are adding unfamiliar architectural weirdness, else why get involved. The big problem is that the pervasiveness of the C model has fossilized design decisions of the PDP-11 that still h…

Yes, absolutely you should have a point to make with your new architecture, and that's likely to involve at least some weirdness. What I'm trying to get at is that the weirdness budget isn't infinite, and therefore you want to be careful to spend it on making your point, not frittering it away on incidentals.

Oh I agree, I was mainly commenting that the size of that “budget” is smaller than it should be, because of the malign influence of C.

Re: The x86 architecture is the weirdo, part 2

#112

Post by mepian »

monocasa wrote: post #54
grishka wrote: post #23

Earlier quoted context omitted.

> exceeding the weirdness budget with VLIW nonsense I feel like the Russian "Elbrus" architecture did the same exact thing.

They hide it well though, like transmeta.

If you mean the x86 emulation, it's not supposed to be the default mode of operation.

Re: The x86 architecture is the weirdo, part 2

#113

Post by gumby »

titzer wrote: post #103
pornel wrote: post #95

Earlier quoted context omitted.

This is roughly what happens, but you shouldn't attribute this to rudeness. Compiler users also demand performance. They compare implementations (and languages) and point out when such-and-such is X% slower. They file bugs about "missed" optimizations and "unnecessary" instructions. C is especially awkward here, because compilers are expected to precisely conform the C specification, but at the same time C users don'…

You make some good points. C was often used in the situation where "Hey, we just built this enormous supercomputer for LLNL, let's make this C program run as fast as possible on this one machine. Compiler team, please do everything possible to get the maximum performane out of this machine." I feel like a lot has followed from this repeating dozens of times over the past few decades. Performance has been the #1 prior…

Not sure if the S-1 is a good example — IIRC it still had a 36-bit word and was mainly intended for pl1 and lisp (I only really saw it from the S-1 Lisp side). Was there evening a C for it? It would have been as bad as running C on a Cray YMP (which I mention above)

Re: The x86 architecture is the weirdo, part 2

#114

Post by CalChris »

snvzz wrote: post #10
KptMarchewa wrote: post #7

Earlier quoted context omitted.

What does ARM and RISC-V spend their weirdness budget on?

As far as I am aware, RISC-V spends it on not being weird (which is itself weird).

Lack of condition codes when the dominant paradigm (x86, ARM) is condition codes is weird. However, having 32 registers unlike x86_64's 16 makes up for some of it.

The base is too base and their bitfield extension is weird.

Re: The x86 architecture is the weirdo, part 2

#115

Post by bpye »

cesarb wrote: post #27
pjc50 wrote: post #15

Earlier quoted context omitted.

MIPS delay slots were another example of this. Arguably Itanium's failure was due to exceeding the weirdness budget with VLIW nonsense, leading to the default PC 64-bit architecture being AMD's "x86 with longer registers" instead. What happened to the Mill "unlimited weirdness budget" CPU guys anyway?

> Arguably Itanium's failure was due to exceeding the weirdness budget with VLIW nonsense Being VLIW was probably the least weird part of Itanium. The NaT ("not a thing") bit on every register was the weirdest part and probably the one which tripped people the most. And like SPARC, it had register windows. It also had a pair of stacks instead of a single one, a set of predicate registers (which also had their own reg…

x86 sort of has two stacks today as a security mitigation https://techcommunity.microsoft.com/t5/windows-kernel-intern...

Re: The x86 architecture is the weirdo, part 2

#116

Post by my123 »

paulmd wrote: post #106
my123 wrote: post #72

Earlier quoted context omitted.

> And we have CUDA which is an attempt to, yes, get back to the C model CUDA allows different programming models, it's the point of having the PTX virtual machine as the exposed programming model. CUDA C++ is popular, but is far from the only option people have. (and it can go very deep, https://www.ibm.com/docs/en/sdk-java-technology/8?topic=egpu... for example)

It's far less popular than the C/C++ bindings (at least at an end-user level), but NVIDIA actually has official support for FORTRAN on CUDA as well. iirc you can mix and match at the linker level, and there's a fair amount of library code that uses FORTRAN for performance reasons. FORTRAN has tighter restrictions around what you can do in terms of aliasing/etc, which allows compilers to be more aggressive about optim…

> at least at an end-user level

I'd say that the most popular option at the end-user level today is a whole level of abstraction above: using Python w/ PyTorch (or less frequently, TensorFlow).

Combined with CuPy and cuNumeric, which is available at https://developer.nvidia.com/cunumeric and handles scaling to multiple machines with Python-written code, through the Legate runtime (https://nv-legate.github.io/legate.core/README.html). This covers a huge amount of what the CUDA userbase uses.

Re: The x86 architecture is the weirdo, part 2

#117

Post by bpye »

pm215 wrote: post #28
KptMarchewa wrote: post #7

Earlier quoted context omitted.

What does ARM and RISC-V spend their weirdness budget on?

You could argue that Arm mostly doesn't get too weird and that that's part of why it succeeded, but some things include: + 'char' being unsigned + handling of unaligned accesses (in early architecture versions a value is read from the aligned address and rotated, which is useless behaviour that falls out of the original implementation because of how it dealt with byte loads; subsequently it was at least made to fault…

I’m pretty sure it’s x86 that is weird in having a strong memory model, most other architectures (including ARM) are weak.

Re: The x86 architecture is the weirdo, part 2

#118

Post by adapteva »

adrian_b wrote: post #18
snvzz wrote: post #10

Earlier quoted context omitted.

As far as I am aware, RISC-V spends it on not being weird (which is itself weird).

The weirdest things about RISC-V are having very weak addressing modes in comparison with almost all other CPU architectures and also having extremely weak support for detecting integer overflow.

Going back to the original H&P texts and RISC philosophy, there is a claim that auto-increment addressing modes is too expensive due to the extra port in the RF + scheduling complexity. For an instruction set that should support embedded in order dual issue processors with math intensive loops, this is arguably a "weird" omission in the base line.

Re: The x86 architecture is the weirdo, part 2

#119

Post by monocasa »

mepian wrote: post #112
monocasa wrote: post #54

Earlier quoted context omitted.

They hide it well though, like transmeta.

If you mean the x86 emulation, it's not supposed to be the default mode of operation.

Its supposed to be a valid way to use the chip. The Russian military has a lot of windows systems and wants to run that on domestically developed chips that don't have a management engine.

Re: The x86 architecture is the weirdo, part 2

#120

Post by AnimalMuppet »

titzer wrote: post #74
notacoward wrote: post #50

Earlier quoted context omitted.

So which language has handled ILP, OOO, delay slots, cache hints, etc. particularly well? Anything that's ergonomic and actually used (i.e. not awkward and academic)?

These are all microarchitectural things that should not be surfaced in language, IMHO. This is why compilers exist, to raise the level of abstraction . For example, other than sidechannels (i.e. Spectre), OOO is not observable , nor is ILP or cache hints. Delay slots are observable at the ISA level but typically compilers do the work of dealing with them. Thank god delay slots didn't make it into programming language…

> Can you imagine if you had a bizarre feature where the next line of code after a branch still executed even if the branch was taken?

I seem to recall that there was a mainframe back in the 1970s that actually did that. Univac 1108 or 1100, maybe? Maybe only in some particular mode?

Post reply on HN