The x86 architecture is the weirdo, part 2 • Hacker News Board

Re: The x86 architecture is the weirdo, part 2

#11

Post by pjc50 » Fri, Apr 22, 2022, 10:16 AM UTC

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?

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.

Re: The x86 architecture is the weirdo, part 2

#12

Post by TNorthover » Fri, Apr 22, 2022, 10:17 AM UTC

snvzz wrote: post #10

KptMarchewa wrote: post #7

Earlier quoted context omitted.

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

The hoops they had to go through to get PIC address calculations to work make it quite weird. Because `auipc` adds an offset from its `pc`, the corresponding `add` or `lw` relocation needs refer back to that instruction rather than the symbol it's actually looking for.

The poor ELF specification ends up quite tortured by this, IMO.

Re: The x86 architecture is the weirdo, part 2

#13

Post by rwmj » Fri, Apr 22, 2022, 10:18 AM UTC

snvzz wrote: post #10

KptMarchewa wrote: post #7

Earlier quoted context omitted.

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

Probably on copying Arm too much :-) I hit "char is unsigned" (not really architectural, more of a toolchain issue) only this morning.

RISC-V was originally going to implement a hypervisor mode which would only have worked with Xen-like hypervisors. Luckily we were able to head that off early and the actual hypervisor extension we got can run KVM efficiently.

Re: The x86 architecture is the weirdo, part 2

#14

Post by rwmj » Fri, Apr 22, 2022, 10:21 AM UTC

pjc50 wrote: post #11

KptMarchewa wrote: post #7

Earlier quoted context omitted.

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

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.

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.

Re: The x86 architecture is the weirdo, part 2

#15

Post by pjc50 » Fri, Apr 22, 2022, 10:23 AM UTC

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…

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?

Re: The x86 architecture is the weirdo, part 2

#16

Post by kryptiskt » Fri, Apr 22, 2022, 10:31 AM UTC

snvzz wrote: post #10

KptMarchewa wrote: post #7

Earlier quoted context omitted.

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

It doesn't have a condition code register, which scores it plenty of weirdness points.

Re: The x86 architecture is the weirdo, part 2

#17

Post by zozbot234 » Fri, Apr 22, 2022, 10:34 AM UTC

kryptiskt wrote: post #16

snvzz wrote: post #10

Earlier quoted context omitted.

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

It doesn't have a condition code register, which scores it plenty of weirdness points.

Not having condition codes actually cleans up the semantics a lot - no need to define the CC effects for each and every insn. It's also helpful to high-performance implementations, since the condition code register would otherwise enter as a dependency in every insn.

Re: The x86 architecture is the weirdo, part 2

#18

Post by adrian_b » Fri, Apr 22, 2022, 10:39 AM UTC

snvzz wrote: post #10

KptMarchewa wrote: post #7

Earlier quoted context omitted.

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

The weirdest things about RISC-V are having very weak addressing modes in comparison with almost all other CPU architectures and also having extremely weak support for detecting integer overflow.

Re: The x86 architecture is the weirdo, part 2

#19

Post by kryptiskt » Fri, Apr 22, 2022, 10:49 AM UTC

zozbot234 wrote: post #17

kryptiskt wrote: post #16

Earlier quoted context omitted.

It doesn't have a condition code register, which scores it plenty of weirdness points.

Not having condition codes actually cleans up the semantics a lot - no need to define the CC effects for each and every insn. It's also helpful to high-performance implementations, since the condition code register would otherwise enter as a dependency in every insn.

Sure, there are reasons for it being that way, but it makes it stick out from the mainstream. For example, if you're writing a codegen, before RISC-V you could assume that you had CMOVE and now you can't. The risk is then that the RISC-V backend will emit some clumsy sequence that emulates CMOVE, to make it fit in with the others.

Re: The x86 architecture is the weirdo, part 2

#20

Post by voldacar » Fri, Apr 22, 2022, 11:07 AM UTC

pjc50 wrote: post #15

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…

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.