Live data from Hacker News

The x86 architecture is the weirdo, part 2

devblogs.microsoft.com

121–130 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#121
post #84

Earlier quoted context omitted.

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.

I'm not sure that you'd do that even on a microcontroller. If you don't have the ROM space, you probably also don't have the transistor budget for the decoder you'd need to handle that.

Re: The x86 architecture is the weirdo, part 2

#122
post #38
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…

> the pervasiveness of the C model has fossilized design decisions of the PDP-11

This is tangential and somewhat pedantic, but I want to point out an oft-repeated mischaracterization.

C is essentially a refinement of B with some additions [1], and B was written for the PDP-7, which was a very different machine.

For example, the increment and decrement operators in C were inherited from B; they could not have been modelled after the PDP-11. From Dennis Ritchie himself [2]:

> Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7, however, did have a few "auto-increment" memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own.

Another person puts it this way [3]:

> It's a myth to suggest C's design is based on the PDP-11. People often quote, for example, the increment and decrement operators because they have an analogue in the PDP-11 instruction set. This is, however, a coincidence. Those operators were invented before the language [i.e. B] was ported to the PDP-11.

[1] Notably, the char type, since the PDP-11 was byte addressable but the PDP-7 was not.

[2] https://www.bell-labs.com/usr/dmr/www/chist.html

[3] https://retrocomputing.stackexchange.com/questions/8869/have...

Re: The x86 architecture is the weirdo, part 2

#123
post #93
post #42

Earlier quoted context omitted.

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

Do they? They came through people who used a right-to-left script (the Arabs). But they originated in India. Did they use right-to-left?

Re: The x86 architecture is the weirdo, part 2

#124

That's not an x86 weirdness, it's just a choice by Microsoft. It's Windows-on-x86 weirdness.

This is what I thought, but the rest of the discussion is way outside my knowledge, so I can't tell what I'm missing.

Can someone explain how is this x86's fault?

Re: The x86 architecture is the weirdo, part 2

#125
This isn't about x86 architecture but historical design choices that then got frozen into an ABI. When Microsoft implemented SEH on ia32, the current approach of lookup table based exceptions (trading memory for runtime code execution, particularly reducing the latter in a success case) was not yet in vogue. When they ported to other architectures and had a choice to introduce a different ABI, they did.

Re: The x86 architecture is the weirdo, part 2

#126
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…

I think they are claiming a savings on a register file, which is not nothing, but not exactly a ton. Also they save on register renaming and scoreboards, which have some gate count.

The biggest thing that they seem to have is that they can compute an enormous number of instructions per cycle without blowing up the size of the bypass network.

Re: The x86 architecture is the weirdo, part 2

#127
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 upwards-growing stack: far more logical when one thinks about it, because in an upwards growing stack, the limit of the stack is the available memory, rather than some arbitrary size decided by someone arbitrarily.

SPARC register windows: once one gr0ks them, they are a feature of wonder! The register windows in an UltraSPARC processor effectively provide 256 virtual registers in a processor with only 32 physical ones, giving one increased performance.

Re: The x86 architecture is the weirdo, part 2

#128
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…

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)?

Fortran. This essay sums it up rather well: https://news.ycombinator.com/item?id=31123165

Re: The x86 architecture is the weirdo, part 2

#129
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 chang…

That's because it is insane: how come most processors are big endian, how did they manage just fine?

Re: The x86 architecture is the weirdo, part 2

#130
post #90

Earlier quoted context omitted.

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 tha…

Loading and storing multiple registers is by no means weird: the MC68000 family has the movem.(b|w|l) instructions which do exactly that, and it's one of the best things since sliced bread because performance can be gained when used cleverly.

Being able to manipulate the program counter in the ARM processors directly is just being honest, simple and straightforward, rather then having it always done implicitly. Seems very intuitive to me now that I think about it.

Post reply on HN