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

31–40 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#31

Post by DSingularity »

voldacar wrote: post #20
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?

The mill guys post one or two updates per year on their forum site. Apparently covid messed up their timeline a lot, but they aren't bankrupt or anything.

What is up with those guys?

Re: The x86 architecture is the weirdo, part 2

#32

Post by thedeadfish »

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.

Re: The x86 architecture is the weirdo, part 2

#33

Post by [deleted] »

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 ?

[deleted]

Re: The x86 architecture is the weirdo, part 2

#34

Post by gumby »

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 and not do from CLOS) and there was never a consideration of doing anything that might impact runtime performance.

At least now I finally understand why some people, especially in the game industry, want to disable exceptions.

As a side point, I'm disappointed by Raymond's (18 yo) claim that "Zero cost exceptions" aren't really zero cost. Everything called "zero cost" in C++ means "doesn't add any runtime cost if you don't use it". He argued against a straw man.

Re: The x86 architecture is the weirdo, part 2

#36

Post by twoodfin »

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…

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, and that ported code included pretty much every weird function entry/exit sequence you could think of (and lots more that you wouldn’t imagine anyone would ever think of). Switching to table-based metadata would have required modifying all that code, making porting more difficult. At least, I assume that’s the reasoning – I was deeply involved in the SEH runtime code in the ’90s and ’00s when I was on the VC++ compiler team.

Re: The x86 architecture is the weirdo, part 2

#37

Post by renox »

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?

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

Re: The x86 architecture is the weirdo, part 2

#38

Post by gumby »

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 haunt us to this day. For example a lot of transistors are devoted to hiding the effects of the micromachine (superscalar implementation, OOO execution etc). Newer paradigms (even trivial older ones like vector instructions) don't get used enough because of higher level language constraints (e.g. C's memory aliasing model). There's a lot of innovation going on but it's all stick in one small bay of a large lake.

Re: The x86 architecture is the weirdo, part 2

#39

Post by twoodfin »

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…

This article isn’t really about x86’s weirdness as an architecture so much as it’s about Windows’ unusual implementation choices particular to that architecture.

Re: The x86 architecture is the weirdo, part 2

#40

Post by gumby »

DSingularity wrote: post #31
voldacar wrote: post #20

Earlier quoted context omitted.

The mill guys post one or two updates per year on their forum site. Apparently covid messed up their timeline a lot, but they aren't bankrupt or anything.

What is up with those guys?

I don't think they know how to move a project forward. What's it been, 20 years?
Post reply on HN