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

51–60 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#51

Post by mech422 »

silon42 wrote: post #45
eadmund wrote: 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…

Stack grows down because it can then potentially use the same as unused heap (which grows from bottom) But then again, HPPA makes it more obvious that stack should be limited size because the above only works for single-threaded processes Worse things about HPPA is delayed jumps... no wonder they were the ones that partnered with Intel on Itanium. Network has no natural order (do you start with the last bit?)... for…

>>Network has no natural order

"When the bytes which make up such multi-byte numbers are ordered from most significant byte to least significant byte, that is called "network byte order" or "big endian." (1)

Seems pretty straightforward MSB to LSB? which is what I learned way back in 'C' times...Did something change ?

1) https://datatracker.ietf.org/doc/html/draft-newman-network-b...

Re: The x86 architecture is the weirdo, part 2

#52

Post by gpderetta »

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…

Re the zero cost claim, he specifically clarifies that zero cost exceptions have a cost even if you do not use them, which is paid by inhibiting some optimizations.

IANACW, but I think that in principle is almost always possible to implement truly zero cost exception path in the non-taken path, by moving all necessary compensation code to undo optimizations into the exceptional path, but in practice it might be too hard for compilers to do it.

Re: The x86 architecture is the weirdo, part 2

#53

Post by mech422 »

rhn_mk1 wrote: post #46
silon42 wrote: post #45

Earlier quoted context omitted.

Stack grows down because it can then potentially use the same as unused heap (which grows from bottom) But then again, HPPA makes it more obvious that stack should be limited size because the above only works for single-threaded processes Worse things about HPPA is delayed jumps... no wonder they were the ones that partnered with Intel on Itanium. Network has no natural order (do you start with the last bit?)... for…

Network does have a natural order. You can make a routing decision faster when you get the most significant units first. If you get the least first, you have to wait for the entire address before you can route to it.

Oh cool - I never knew this was the reason why...

Thanks!

Re: The x86 architecture is the weirdo, part 2

#54

Post by monocasa »

grishka wrote: post #23
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?

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

Re: The x86 architecture is the weirdo, part 2

#55

Post by rwmj »

gchadwick wrote: post #43
rwmj wrote: post #14

Earlier quoted context omitted.

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.

> Instruction sequences that fuse are standardized They are? Care to point to a ratified RISC-V standard that lists said instruction sequences?

Go to the user spec here: https://riscv.org/technical/specifications/ and search for "fusion", "macro-op", "hint", "two-instruction sequences". A lot of it is through register choice. For other proposals (not standards yet) see https://en.wikichip.org/wiki/macro-operation_fusion#Proposed...

Re: The x86 architecture is the weirdo, part 2

#56

Post by gpderetta »

thedeadfish wrote: post #32
rpasquay wrote: post #25

I did not understand why on x86 Windows/MSVC cannot implement exceptions the same way as it was done for other architectures. I read that on x64 a different approach is used ("table based" - sounds to me like the "unwind code" approach mentioned in the article). Is this not possible no x86 for some reason ?

Table based exceptions only work if everyone plays ball. Its not practical to introduce them after the fact because they will not work with any existing code including OS callbacks. AMD64 can use them because they were there from the beginning.

On linux they are also used for x86-32. The previous sjlj ABI was broken about 20 years ago when the Itanium ABI was introduced.

Re: The x86 architecture is the weirdo, part 2

#57

Post by someguydave »

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…

> C's memory aliasing model

does this mean that because you can’t be sure if two vectors don’t overlap in C you therefore can’t auto-vectorize loops?

Re: The x86 architecture is the weirdo, part 2

#58

Post by GPerson »

cesarb wrote: post #47
eadmund wrote: 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…

> To be honest, I never really understood why more architectures don't have upwards-growing stacks. A downward-growing stack is more intuitive. To access items on a downward-growing stack, you use positive offsets; for instance, sp+0x10 could be the second stack-passed argument to a function. For an upward-growing stack, you have to use negative offsets. > Hard disagree, big-endian is right and little-endian is wrong…

“ A downward-growing stack is more intuitive. To access items on a downward-growing stack, you use positive offsets; for instance, sp+0x10 could be the second stack-passed argument to a function. For an upward-growing stack, you have to use negative offsets.”

I would expect you to use negative offsets to access the previous elements.

Re: The x86 architecture is the weirdo, part 2

#59

Post by rwmj »

renox wrote: post #37
KptMarchewa wrote: post #7

Earlier quoted context omitted.

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

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.

Re: The x86 architecture is the weirdo, part 2

#60

Post by monocasa »

pjc50 wrote: post #41
twoodfin wrote: post #36

Earlier quoted context omitted.

There’s a comment on Raymond’s post that explains it in a plausible-sounding way: https://devblogs.microsoft.com/oldnewthing/20220418-00/?p=10... Table-based exception-handling metadata requires function prologue/epilogue sequences to have constrained forms that can be described by that metadata. When NT was first designed for x86-32, there was a lot of existing asm code that people wanted to easily port over to NT,…

> SEH runtime Note that in Microsoft compiler land there are two kinds of exception, regular C++ ones and "structured exception handling". https://docs.microsoft.com/en-us/cpp/cpp/try-except-statemen... The latter does exception unwinding in the kernel on runtime faults (segv, division by zero, etc). It does _not_ unwind destructors or deallocate storage. And yes, I know about this because I had to debug it, on WinCE…

Sort of. C++ exceptions are built off of SEH on MSVC.
Post reply on HN