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

91–100 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#91

Post by gumby »

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…

Think about it the other way around: if the language were sufficiently high level that the compiler could give the CPU more opportunities for OOO. C incorporates too many assumptions about the PDP-11. Sometimes they are harmless (the ++ operator) and sometimes disastrous (memory model).

Re: The x86 architecture is the weirdo, part 2

#92

Post by cestith »

pjc50 wrote: post #11
KptMarchewa wrote: post #7

Earlier quoted context omitted.

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

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.

POWER architecture endianness is also switchable at runtime. https://developer.ibm.com/articles/l-power-little-endian-faq...

Re: The x86 architecture is the weirdo, part 2

#93

Post by de_huit »

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

Our numbers originate from people using a right-to-left script...

Re: The x86 architecture is the weirdo, part 2

#94

Post by titzer »

SuchAnonMuchWow wrote: post #83
titzer wrote: post #74

Earlier quoted context omitted.

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.

Fair point, but I'd qualify that OOO is only observable for racy programs. In languages with shared memory concurrency, but safety, races are either statically disallowed (Rust), or their results are constrained by a (weak) memory model. Java, e.g. only makes rough guarantees that you don't see out-of-thin air values and that you can't violate the type system. Java also is a little stricter around volatile memory access (they are sequentially consistent, iirc). Also worth noting, some reorderings that you see are not due to hardware, but due to compiler optimizations. Compilers have to obey the memory model, too.

Generally, most programmers shouldn't need to be reasoning about OOO or memory order and be using fences. Rather, they should use libraries that are written by experts that use extra-lingual mechanisms (like compare-swap or fences) to guarantee a higher contract.

Re: The x86 architecture is the weirdo, part 2

#95

Post by pornel »

titzer wrote: post #71
gumby wrote: post #62

Earlier quoted context omitted.

That's an example. It also constrains some optimizations like reordering.

> It also constrains some optimizations like reordering. Ha! As if C compilers really cared about correctness. This is why type-punning and aliasing memory through different typed pointers is fraught with peril, often UB. It's so C compilers can cheat and use type-based alias analysis, breaking programs that have "UB" but would work absolutely fine if the compiler wasn't so aggressive. In general, almost all argument…

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't actually want to program for the abstract machine from the C specification (the one that can't overflow signed integers or shift by a full int width). C users expect their programs to actually behave like programs for a particular hardware they target, without any overhead or discrepancy from "emulating" the imaginary C-spec machine. In face of such conflicting requirements, C compilers will always be forced to balance performance, predictability, conformance, and compatibility.

Re: The x86 architecture is the weirdo, part 2

#96

Post by nneonneo »

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…

I mean, people did try to do everything all at once, and the results are therefore dead and forgotten (cough Itanium cough).

Re: The x86 architecture is the weirdo, part 2

#98

Post by rwmj »

monocasa wrote: post #82
rwmj wrote: post #59

Earlier quoted context omitted.

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.

I didn't put that very well. I didn't mean it was self-synchronising when executing, but that you can (I think?!) always find the next instruction boundary by looking at the bottom bits. At least, that's my understanding from reading that part of the user spec.

Re: The x86 architecture is the weirdo, part 2

#99

Post by jayd16 »

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…

You can generalize this to a developer/user friction budget.

Re: The x86 architecture is the weirdo, part 2

#100

Post by gotaquestion »

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…

As a former microarchitect, the contortions designs take on is due to a combination of factors, usually stemming from routing/timing problems in the design or backwards compatibility, and every now and then, compiler team requests.

For example, endian-ness looks like weirdness to a programmer, but not to a chip designer that needs to read in lower-order bytes first to decode an instruction quickly. Why not just change the instruction decoder? Because it needs to be backwards compatible to what was once a byte-sized ISA.

But for programmers who don't understand the history, it seems insane.

Post reply on HN