The x86 architecture is the weirdo, part 2
devblogs.microsoft.com
The x86 architecture is the weirdo, part 2
1–10 of 170 posts
Re: The x86 architecture is the weirdo, part 2
#2It 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.
Re: The x86 architecture is the weirdo, part 2
#3I 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 :-)
Re: The x86 architecture is the weirdo, part 2
#4It 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.
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.
Re: The x86 architecture is the weirdo, part 2
#5It 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.
Why? Fs:[0] works out to [FsBase] which is just another store through a pointer.
Re: The x86 architecture is the weirdo, part 2
#6It 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.
Why? Fs:[0] works out to [FsBase] which is just another store through a pointer.
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.
Re: The x86 architecture is the weirdo, part 2
#7I 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?
Re: The x86 architecture is the weirdo, part 2
#8It 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.
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.
In the article example itself, f1() and f2() can observe the state. Nothing to do with threads.
Re: The x86 architecture is the weirdo, part 2
#9I 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?
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
Re: The x86 architecture is the weirdo, part 2
#10I 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?
As far as I am aware, RISC-V spends it on not being weird (which is itself weird).