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

131–140 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#131

Post by xenadu02 »

mech422 wrote: post #53
rhn_mk1 wrote: post #46

Earlier quoted context omitted.

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!

This is mostly irrelevant today though; the hardware is so much faster and memory so much more plentiful that handling is done by reading the full header (and often full packet) then making the routing or forwarding decision. You don't need to squeeze out every single cycle or save every single byte possible. You have so much headroom saving cycles or bytes makes no difference and you can't optimize enough to make significant BOM reductions by choosing cheaper chips while still offering features considered standard. Even if you could you'd be selling into an ultra-ultra-cheap market segment no one cares about (congrats, you made a $2 10Mbps router that can run on a coin cell battery).

Re: The x86 architecture is the weirdo, part 2

#132

Post by Annatar »

rwmj wrote: post #55
gchadwick wrote: post #43

Earlier quoted context omitted.

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

just one example of weird insanity from that table:

slli rd, rs1, {1,2,3}

add rd, rd, rs2 Fused into a load effective address

...this is so insane. Whoever thought that this is okay and good, has, in my opinion, severe psychological and psychiatric problems and would do well to seek professional help. If this gets "fused" into a lea, why just not implement a hex code for lea? I'm just completely at a loss as to how messed up that is.

You know what, I'd like to know what a person who thinks that this is okay looks and behaves like.

Re: The x86 architecture is the weirdo, part 2

#133

Post by mhh__ »

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 think they don't have a rich enough VC friend, and they need a kick up the arse before (to be blunt) they get too old.

Ivan was saying that they weren't sure about how to get money, and then someone quite rightfully pointed out that this is probably the most liquid time in years for funding startups.

Mill team if you're reading this: Get your IP sorted out then open source everything, then start talking to VCs aggressively. Not the other way round because everyone thinks you're either a joke or a group of fantasists.

Cool ISA, hopeless execution. Where's the FPGA model?

Re: The x86 architecture is the weirdo, part 2

#134

Post by gchadwick »

rwmj wrote: post #55
gchadwick wrote: post #43

Earlier quoted context omitted.

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

So searching by the terms you give the actual spec lists two possibilities a lui/jalr pair, a auipc/jalr pair. Plus they're not given as 'these are the blessed instruction pairs high performance implementations should seek to fuse' but more 'you can do this if you want'. You could maybe count the return address stack hints but they're not about instruction fusion, just a common branch predictor optimisation.

An unsourced table on Wikichip (which was added in 2019 and not updated since) barely counts as a proposal (in terms of it standing a good chance of becoming part of a ratified RISC-V standard).

No doubt many high performance implementations will choose to use fusion and no doubt they'll all go for different combinations, with different edges cases. Yes there likely will be significant overlap but it could become a bit of a nightmare for a compiler writers. A thorough standardized list of instruction pairs to fuse would definitely help here, but we don't have one.

Re: The x86 architecture is the weirdo, part 2

#135

Post by pclmulqdq »

mhh__ wrote: post #133
DSingularity wrote: post #31

Earlier quoted context omitted.

What is up with those guys?

I think they don't have a rich enough VC friend, and they need a kick up the arse before (to be blunt) they get too old. Ivan was saying that they weren't sure about how to get money, and then someone quite rightfully pointed out that this is probably the most liquid time in years for funding startups. Mill team if you're reading this: Get your IP sorted out then open source everything, then start talking to VCs aggr…

The mill folks don't care for investment. Most of them are already very rich. They also aren't big on openness: they have a ton of patents.

Re: The x86 architecture is the weirdo, part 2

#136

Post by pclmulqdq »

Annatar wrote: post #132
rwmj wrote: post #55

Earlier quoted context omitted.

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

just one example of weird insanity from that table: slli rd, rs1, {1,2,3} add rd, rd, rs2 Fused into a load effective address ...this is so insane. Whoever thought that this is okay and good, has, in my opinion, severe psychological and psychiatric problems and would do well to seek professional help. If this gets "fused" into a lea, why just not implement a hex code for lea? I'm just completely at a loss as to how m…

The bitmanip extension has an LEA equivalent, so it looks like they have backtracked on this one.

Re: The x86 architecture is the weirdo, part 2

#137

Post by giomasce »

russellbeattie wrote: post #124
giomasce wrote: post #97

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?

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.

Re: The x86 architecture is the weirdo, part 2

#138

Post by de_huit »

AnimalMuppet wrote: post #123
de_huit wrote: post #93

Earlier quoted context omitted.

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

The oldest source [1] seems to be in Sanskrit, a left-to-right language, so they were big-endian numbers. This still does not rule out an even older origin in a right-to-left language, but as it stands I'm afraid I was just wrong with my 'little endian origin' story. Too bad, I liked it.

[1] https://mathshistory.st-andrews.ac.uk/HistTopics/Bakhshali_m...

Re: The x86 architecture is the weirdo, part 2

#139

Post by mech422 »

xenadu02 wrote: post #131
mech422 wrote: post #53

Earlier quoted context omitted.

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

This is mostly irrelevant today though; the hardware is so much faster and memory so much more plentiful that handling is done by reading the full header (and often full packet) then making the routing or forwarding decision. You don't need to squeeze out every single cycle or save every single byte possible. You have so much headroom saving cycles or bytes makes no difference and you can't optimize enough to make si…

Huh - I would have thought for higher speed stuff (say 40G+ ?) performance would still be an issue if you wanted to maintain wire speed - Especially driving multiple interfaces ?

I agree home/consumer stuff is just basicly coasting on 3-4 generation tech though. I ran cat-6 cable around the house hoping to get 10G sometime in my lifetime for less then the cost of a kidney...

Re: The x86 architecture is the weirdo, part 2

#140

Post by Slighted »

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…

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.
Post reply on HN