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

81–90 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#81

Post by ribit »

gumby wrote: post #34

MS was stuck with a poor exception implementation but what I never see explain is how they got there in the first place. It seems crazy to incur a runtime overhead to support something that is hardly ever used. The happy path is where you need the performance most, and exceptions are by definition the "unhappy path". Michael and I talked about exception design a lot in g++ (I certainly had experience of what to do an…

C++ exception model is complex and the implementations are intricate. I do not think you one can easily dismiss the possibility of runtime overhead just because it seems like no extra work is done. It's much more subtle that that. The implementation potentially affects inclining opportunities, compiler complexity, code caching etc.

On modern CPUs, probably the most efficient exception model is one that simply uses error codes. Especially when paired with an optimised calling convention like what Swift does. Checking for an error flag is essentially free on a superscalar CPU anyway and all this stuff is transparent to the compiler, simplifying the translation process and enabling more optimisation opportunities.

P.S. I ran a bunch of tests with C++ a while ago and a Result-like type error handling (implemented sanely) was always as fast as C++ exceptions for the good path and faster for the bad path — unless you are going a hundred or so nested functions deep (but then you have a massive code smell problem anyway). With an optimised calling convention it is likely to be even better.

Re: The x86 architecture is the weirdo, part 2

#82

Post by monocasa »

rwmj wrote: post #59
renox wrote: post #37

Earlier quoted context omitted.

In RISC-V with the C-extension 32bit instructions are 16bit aligned. Far from x86-level of weirdness but my must be quite annoying for those who want to make 'high performance' CPUs..

RISC-V instructions are variable length, from 16 bits up to 192 bits[0]. The instruction stream is self-synchronising though so from a hardware decode point of view it's not a problem, unlike x86. [0] See "Expanded Instruction-Length Encoding" in the user spec.

I don't think the instruction stream is self synchronizing; if you jump to the middle of an instruction there's no guarantee you'll ever get back to not parsing garbage.

Re: The x86 architecture is the weirdo, part 2

#83

Post by SuchAnonMuchWow »

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…

OOO is definitely observable when dealing with multithreading.

That's why you have things like memory order constraints on atomic operations in C, and why you need to be extremely careful with how you place things like memory fences when doing anything fine-grained between several threads.

Re: The x86 architecture is the weirdo, part 2

#84

Post by pjc50 »

monocasa wrote: post #79
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?

I might be missing something, but I never figured out where mill was saving all those gates they claimed. It could be my lack of imagination, but the straightforward way to implement the belt just looks like a ROB and bypass network just like a normal OoO core spends it's gates on. And on the frontend, sure they mark instruction boundaries within an instruction bundle, but you still need N barrel shifters (where N is…

Bit aligned instructions? Yeah, that definitely sounds mad, like my joke proposal that instructions should be Huffman-coded so the frequent ones take fewer bits. Might make sense if you're doing a microcontroller with a few K of ROM and need to save bits, but otherwise no.

Re: The x86 architecture is the weirdo, part 2

#85

Post by pm215 »

eadmund wrote: post #42
pm215 wrote: post #3

I have a theory that CPU architectures implicitly have something I call the "architectural weirdness budget", which is the extent to which you can get away with design decisions in the architecture or ABI that differ from the existing established consensus. Any time you do something a bit odd that means that existing software has to do awkward things or might not be no-changes portable to your new architecture, you'r…

> + HPPA's upwards-growing stack To be honest, I never really understood why more architectures don't have upwards-growing stacks. Visually, one adds things to the top of a stack, after all, so it makes sense to increment the stack pointer. I suppose it's a relic of the old days when folks just set the start of the stack to some remote part of memory and hoped it never grew down into the code or the heap? > + these d…

On endianness, I'm not making a claim that one or the other is "better" or "right" -- merely that little-endian architectures are pervasive in the current world, and so picking big-endian for a hypothetical new architecture would be unnecessarily forcing it to deal with "this software is buggy on big-endian" issues forever. Which is fine if there is some really strong reason your new architecture should be big-endian; but if it's mere aesthetic preference then the cost probably outweighs the benefit right now.

Re: The x86 architecture is the weirdo, part 2

#86

Post by pm215 »

rwmj wrote: post #59
renox wrote: post #37

Earlier quoted context omitted.

In RISC-V with the C-extension 32bit instructions are 16bit aligned. Far from x86-level of weirdness but my must be quite annoying for those who want to make 'high performance' CPUs..

RISC-V instructions are variable length, from 16 bits up to 192 bits[0]. The instruction stream is self-synchronising though so from a hardware decode point of view it's not a problem, unlike x86. [0] See "Expanded Instruction-Length Encoding" in the user spec.

It can still get you into some extra corner cases for the insn fetch hardware to have to handle when an insn crosses a cache line boundary, though...

Re: The x86 architecture is the weirdo, part 2

#87

Post by Jasper_ »

rwmj wrote: post #14
pjc50 wrote: post #11

Earlier quoted context omitted.

RISC-V spends it on the "R": either not having single instructions to do certain stuff, or that those instructions are in one of the extension blocks so you have to customize your binaries to a particular RISC-V subset. Most architectures only do this for the high-performance SIMD numeric instructions. ARM endianness is switchable at runtime.

You keep saying this about RISC-V and it keeps not being true. Instruction sequences that fuse are standardized. RISC-V defines various profiles (like "Unix server") which mandate a minimum set of extensions. Extensions beyond the mandated ones will be detected at runtime, just like on x86.

Fusion isn't cheap and I'd say it's part of the weirdness bucket to rely on fusion instead of making a combined instruction.

Re: The x86 architecture is the weirdo, part 2

#88

Post by SuchAnonMuchWow »

eadmund wrote: post #42
pm215 wrote: post #3

I have a theory that CPU architectures implicitly have something I call the "architectural weirdness budget", which is the extent to which you can get away with design decisions in the architecture or ABI that differ from the existing established consensus. Any time you do something a bit odd that means that existing software has to do awkward things or might not be no-changes portable to your new architecture, you'r…

> + HPPA's upwards-growing stack To be honest, I never really understood why more architectures don't have upwards-growing stacks. Visually, one adds things to the top of a stack, after all, so it makes sense to increment the stack pointer. I suppose it's a relic of the old days when folks just set the start of the stack to some remote part of memory and hoped it never grew down into the code or the heap? > + these d…

> Hard disagree, big-endian is right and little-endian is wrong. At least, unless you think this year is 2202.

If you think a bit about it, it would have been much more natural to write number in the opposite order compared to what we have now, since we read and manipulate numbers from least-significant digit to most-significant digit and read text left-to-right.

When you read a number like 346624596, you need to parse it twice to know its value, but also to know its magnitude or do anything significant with it. In the opposite order, everything becomes simpler: adding two numbers, knowing the magnitude or ignoring the least-significant digits ("its about 350 millions"), ...

Re: The x86 architecture is the weirdo, part 2

#89

Post by pm215 »

gumby wrote: post #38
pm215 wrote: post #3

I have a theory that CPU architectures implicitly have something I call the "architectural weirdness budget", which is the extent to which you can get away with design decisions in the architecture or ABI that differ from the existing established consensus. Any time you do something a bit odd that means that existing software has to do awkward things or might not be no-changes portable to your new architecture, you'r…

> 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.

Re: The x86 architecture is the weirdo, part 2

#90

Post by cesarb »

KptMarchewa wrote: post #7
pm215 wrote: post #3

I have a theory that CPU architectures implicitly have something I call the "architectural weirdness budget", which is the extent to which you can get away with design decisions in the architecture or ABI that differ from the existing established consensus. Any time you do something a bit odd that means that existing software has to do awkward things or might not be no-changes portable to your new architecture, you'r…

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

For traditional 32-bit ARM, off the top of my head:

- Every instruction being conditional (all instructions have a four-bit condition field, with one of the 16 possible modes being "always");

- The barrel shifter, which can be used on nearly every data processing instruction;

- The program counter being one of the general-purpose registers (and on the original ARM, the same register also containing the flags), so that any register move can alter the program flow;

- The load-multiple/store-multiple instructions, which can load or store up to 16 registers, plus incrementing or decrementing the base register; and since the program counter is one of these registers, it can restore several registers from the stack, update the stack pointer, change the program counter, and switch to Thumb mode (stored on the least significant bit of the program counter), all in a single instruction.

Post reply on HN