The x86 architecture is the weirdo, part 2

https://devblogs.microsoft.com/oldnewthing/20220418-00/?p=106489

by zdw • 4 years ago

175 166 4 years ago

devblogs.microsoft.com

gpderetta6• 4 years ago

It is interesting that the stores to node are seen as dead. Surely the assignment of the node address to fs:[0] should equivalent of assigning it a global variable, so any state change in node can be observed by any function.

foota• 4 years ago

I believe this is because the intermediate state can't be safely observed by another thread, since there's no locking, so the C++ memory model allows removing them.

gpderetta6• 4 years ago

In the article example itself, f1() and f2() can observe the state. Nothing to do with threads.

rayiner• 4 years ago

Why? Fs:[0] works out to [FsBase] which is just another store through a pointer.

gpderetta6• 4 years ago

sure, but that's just a global memory location which any function can read from (I think it is part of Windows thread control block, but do not quote me on that).

Probably stores through fs are pragmatically not considered globals stores as they would hinder other optimizations.

pm2155• 4 years ago

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're spending a bit of your weirdness budget. Some examples:

+ HPPA's upwards-growing stack

+ SPARC register windows

+ PowerPC's slightly oddball varargs ABI

+ CHERI capabilities are massively spending weirdness budget

+ these days, being big-endian is spending weirdness budget

Doing a few odd things is fine, but if you blow your weirdness budget entirely then your new architecture is in danger of failing because you've cumulatively made adoption of it too expensive for the existing software ecosystem. So you need to be careful that you're spending it on things that really matter; if something's not a big deal, do it the same way everybody else does. (Certainly some of the things in the list above are deliberate choices for things that are, or at least seemed at the time, important. But nobody tried to do all of them at once!)

Of course if you're a pre-existing dominant architecture like x86 then you get a lot more freedom to do weird things :-)

KptMarchewa• 4 years ago

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

jmgao2• 4 years ago

ARM spends it on pc being wrong: when you mov from it, it's off by 8 in ARM mode, and off by 4 in Thumb mode, and if you're using it for pc-relative loads (and stores, if you're crazy), it uses a word aligned value.

edit: oh, and softfloat vs softfp vs hardfp vs vfp

edit: oh, and how they have two incompatible assembly language dialects that are mostly the same, but in non-trivial code, incompatible

snvzz2• 4 years ago

As far as I am aware, RISC-V spends it on not being weird (which is itself weird).

pjc504• 4 years ago

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.

pm2155• 4 years ago

You could argue that Arm mostly doesn't get too weird and that that's part of why it succeeded, but some things include:

+ 'char' being unsigned

+ handling of unaligned accesses (in early architecture versions a value is read from the aligned address and rotated, which is useless behaviour that falls out of the original implementation because of how it dealt with byte loads; subsequently it was at least made to fault, but it wasn't until I think v6 that unaligned accesses were made to Just Work)

+ the weak memory model

renox• 4 years ago

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

cesarb3• 4 years ago

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.

qikInNdOutReply• 4 years ago

wasnt there also the long jump limitation weirdness that forced it to create little hopping points, were the instructions were stored to hop to the next point, all of that to get to some memory whos pointer it could not fit into loadInstructions Register?

Sorry, its been a while, but i found the idea, to generate those instruction isles into the code quite weird.

pjc504• 4 years ago

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?

voldacar2• 4 years ago

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.

grishka• 4 years ago

exceeding the weirdness budget with VLIW nonsense

I feel like the Russian "Elbrus" architecture did the same exact thing.

speed_spread• 4 years ago

The fab collects. Weird budget is unlimited as long as you don't tape out. Then the real world hits.

At this point, we can safely say that Mill was just an odd engineer's weird fetish.

cesarb3• 4 years ago

Arguably Itanium's failure was due to exceeding the weirdness budget with VLIW nonsense

Being VLIW was probably the least weird part of Itanium. The NaT ("not a thing") bit on every register was the weirdest part and probably the one which tripped people the most. And like SPARC, it had register windows. It also had a pair of stacks instead of a single one, a set of predicate registers (which also had their own register windows), and plenty of other assorted weirdness.

monocasa6• 4 years ago

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 the number of max instructions per cycle) to get at them, and that's the expensive part of wide decode. Even 16bit aligned is so much nicer for the critical path than 8-bit, bit aligned is absolutely crazy town.

marcosdumay• 4 years ago

The Mill weirdeness is weird in the sense that it's almost perfectly compatible with C-like code. It's not this that is impacting the project.

Instead, launching a new architecture is an herculean task. Trying that inside anything that isn't a huge company or consensus on the academic world has a history of nearly 100% failure since huge companies started building computers. (And even the consensus on the academic world is iffy.)

planede• 4 years ago

You also have to distinguish between the architecture, and an ABI targeting a specific architecture. I believe x86 exception handling is nothing like this on gcc/clang.

gumby12• 4 years ago

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.

notacoward2• 4 years ago

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

someguydave2• 4 years ago

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?

pm2155• 4 years ago

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.

agalunar• 4 years ago

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

Slighted• 4 years ago

What exactly do you mean by the "C model"? Computers have followed the Von Neumann architecture for quite a long time. That PDP-11 is fundamentally the same as a modern computer, albeit millions of times slower. And I'm curious as well what "new paradigms" you have in mind.

twoodfin2• 4 years ago

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.

eadmund• 4 years ago

+ 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 days, being big-endian is spending weirdness budget

Hard disagree, big-endian is right and little-endian is wrong. At least, unless you think this year is 2202. I don't know how Intel got this so badly incorrect.

And remember that network byte order is big-endian. Any protocol which emits little-endian bytes on the wire is broken by design.

silon42• 4 years ago

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 new stuff I'd do the little-endian any way if I cared to bother.

cesarb3• 4 years ago

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.

Little-endian is more natural. With little-endian numbers, the byte b at offset n has value b*256**n; with big-endian numbers, the byte b at offset n has value b*256**(l-n-1).

And remember that network byte order is big-endian.

That's mostly by historical accident; the architectures originally used to implement the network protocols we use nowadays were big-endian. It makes sense in some situations to have on-wire numbers be big-endian, especially network addresses, since it allows the hardware to decide before the whole number arrives; that is less relevant nowadays because not only networks are much faster, but also it's more common to read the whole header to a buffer before making these decisions.

pm2155• 4 years ago

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.

SuchAnonMuchWow2• 4 years ago

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"), ...

de_huit2• 4 years ago

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

titzer9• 4 years ago

+ MSP430 holes in the addressing mode encoding space

I don't know of any new architecture that is choosing big-endian. Almost all of the ones that I can think of that are/were big-endian have added a little-endian mode.

Thank god for that! In Wasm we just decreed little-endian, and I think this was one of our better calls.

nneonneo• 4 years ago

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

jayd16• 4 years ago

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

gotaquestion2• 4 years ago

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.

Annatar7• 4 years ago

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

CalChris2• 4 years ago

+ SPARC tagged integers

+ MIPS branch delay slot

+ Everything about VLIW

+ Everything about Mill

+ iAPX 432 bit variable length instructions

Annatar7• 4 years ago

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.

badrabbit• 4 years ago

For the unaware, SEH can be used by malware to evade detection: https://marcoramilli.com/2011/11/28/pop-pop-ret-seh-exploiti... , also, X64 uses a table based approach in the PE header: https://www.osronline.com/article.cfm%5earticle=469.htm

rpasquay• 4 years ago

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 ?

nikbackm• 4 years ago

The answer seems to be in the follow-up comments to the post.

thedeadfish2• 4 years ago

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.

gpderetta6• 4 years ago

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.

thedeadfish2• 4 years ago

Am I the only one who prefers the way x86 did exceptions? I really don't like that with table based exceptions, every function must include bloated unwind tables, and is also forced to conform to a very restrictive set of code generation rules. It also makes writing and assembly and dynamic code generation difficult.

gumby12• 4 years ago

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.

twoodfin2• 4 years ago

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.

pjc504• 4 years ago

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 ARM, where we eventually discovered that there were two different MS compilers, one of which generated code that could be unwound and one of which didn't.

gumby12• 4 years ago

Thanks. A legacy of lots of assembly code, though surprising that stuff like that survived in libraries (in applications it probably wouldn't have mattered)

gpderetta6• 4 years ago

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.

gumby12• 4 years ago

If you spend a lot of time scrutinizing g++ output (which thankfully I haven't had to do in over 20 years) you'll see that the impact is negligible and that was true when Raymond made that statement. As you point out there's a lot the compiler can do to make the common path really fast.

But OK, it could potentially be nonzero. Let's say epsilon cost instead.

ribit• 4 years ago

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.

AlexandrB• 4 years ago

I'm bummed that The Old New Thing is now on Microsoft's domain. Old blogs seems to be dying out or being moved behind the walls of Medium/Substack/etc.

jcranmer• 4 years ago

I'm bummed that The Old New Thing is now on Microsoft's domain.

Um, it's always been on MS's domain. It has moved from e.g. msdn.com (I think) to microsoft.com, but that's more about MS periodically moving around where its documentation is hosted because shrug, but it was always in same way officially hosted by MS.

mschaef• 4 years ago

It's always been on one Microsoft domain or another, for almost as long as there've been blogs at all. It's almost 20 years ago now, but when Blogs started their initial ascendency as a useful format, Microsoft had a a number of developers start writing publicly facing personal blogs. Raymond Chen was one of that group, also including Michael Kaplan, Eric Lippert and Larry Osterman, among others.

As far as I know, The Old New Thing is the only blog from that wave that's still being written - and it's been written every weekday for essentially that entire time. To give an idea of the scope of the work, he did a compilation of posts in book form sixteen years ago, and it was over 500 pages long.

https://www.amazon.com/gp/product/B004YWCL5W/ref=dbs_a_def_r...

I don't read it daily anymore (hasn't been relevant to my work or professional interests for ten years or more), but I do read it occasionally and continue to be both impressed and grateful for the effort he's put into the blog.

titzer9• 4 years ago

This is one of the many reasons that having exceptional control flow explicit in the compiler IR is a Good Thing(tm). The HotSpot client compiler lacked this information (in the beginning) because it was deemed "too expensive to keep" and the result was that many optimizations had ugly special cases (or were disabled altogether). For the most part, if the compiler has some notion of hot/cold code, then these exceptional edges can just be marked as cold and the same heuristics that apply to, e.g. unlikely branches, will do a good job.

ajross• 4 years ago

Pretty much exactly. They had a situation with external visibility into information in the stack frame and don't seem to have made an effort to tell the compiler. I mean... it's their compiler! It's their ABI, even! They have all the levers and dials, and somehow the fact that their exception counter is being optimized out means that the "architecture" is the weirdo?

Yeah. At its root this is a Conway's Law bug. The people responsible for "exceptions" had a senseless wall between them and the people responsible for "stack frames".

titzer9• 4 years ago

Indeed. In Java, on every platform that I know of (including x86 and x86-64), exceptions are zero cost, with no dynamic work needed to enter a try. On Windows they are probably stuck with ABI compatibility. It sounds like the design was flawed from the start and definitely not the architecture's fault.

userbinator• 4 years ago

That state variable is actually quite useful for decompilation too:

http://www.openrce.org/articles/full_view/21

giomasce2• 4 years ago

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

russellbeattie• 4 years ago

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?

giomasce2• 4 years ago

I don't think it is. I don't know if the peculiarities of x86 were considered when Microsoft's engineers decided to do SEH the way it is, but there is no hard reason why they couldn't decide to make it table based.

omoikane• 4 years ago

Isn't it possible to annotate a variable as not being eligible for dead store elimination with something like "volatile"? I wonder why that particular state was causing trouble for Visual C++, assuming that it's able to handle code that deal with other kinds of asynchronous events (e.g. signal handlers).

asveikau• 4 years ago

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.

The x86 architecture is the weirdo, part 2

Related Stories