Live data from Hacker News

The x86 architecture is the weirdo, part 2

devblogs.microsoft.com

161–170 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#161

Earlier quoted context omitted.

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

First off, most processors are not BE. Arm and X86 are LE and cover "most processors". Second, processors like the Motorola 68000 were 32-bit, so there was no need to read just the first byte. Refer to my point about instruction fetch. Like I said, if you have an ISA that came from byte-sized opcodes, and then expanded later, you need to fetch bytes first. However, if your opcodes are 32-bit, then the code is bigger.…

ARM and x86 are only two out of many processors: you are purposely choosing to confuse market dominance with what exists, and I fault you for it, because by behaving in this way, you are helping perpetuate the monoculture.

The moment you help perpetuate a monoculture rather than subvert it and fight it at every turn and opportunity, you become part of the problem.

Re: The x86 architecture is the weirdo, part 2

#162

Earlier quoted context omitted.

Loading and storing multiple registers is by no means weird: the MC68000 family has the movem.(b|w|l) instructions which do exactly that, and it's one of the best things since sliced bread because performance can be gained when used cleverly. Being able to manipulate the program counter in the ARM processors directly is just being honest, simple and straightforward, rather then having it always done implicitly. Seems…

Being able to manipulate the program counter directly plays hell with a superscalar and especially OoO processor where you want to be able to predict what the program counter does very accurately so the instruction fetch and decode can run far ahead of the execution. There are four kinds of instructions that play hell with pipeline and OoO design: - instructions that might cause traps, dependent on the values process…

"An instruction cache also eliminates them, leaving only the code size benefits."

The performance of movem.l in the MC68000 comes not from multiple load, but from multiple store, because the main memory access incurred a tremendous, extremely punitive penalty. This has not changed, even decades later, in systems with the fastest memory chips available: any writes to random access memory incur tremendous penalties.

Re: The x86 architecture is the weirdo, part 2

#163
post #141

Earlier quoted context omitted.

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.

Harvard architecture machines are still not just being used but still being designed these days. Examples of non-pdp-11 things are discussed in various comments in this thread.

Case in point: many microcontrollers. The AVR ISA (made famous in Arduinos) is a modified Harvard architecture.

Re: The x86 architecture is the weirdo, part 2

#164

Earlier quoted context omitted.

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…

I think they are claiming a savings on a register file, which is not nothing, but not exactly a ton. Also they save on register renaming and scoreboards, which have some gate count. The biggest thing that they seem to have is that they can compute an enormous number of instructions per cycle without blowing up the size of the bypass network.

If their goal is to save on register file space, they're barking up the wrong tree, IMO. The Skylake-X die[0], for example, dedicates only about 1% to the integer register file, and only about 2.5% for the floating point register file. The decoder and scheduler also take up only single digit percents.

Granted, this is a top of the line superscalar processor with AVX-512 and megabytes of cache, but my point still stands. The vast majority of the gates are in everything else: cache, execution units, branch prediction, load/store, die interfaces, etc.

[0]: https://twitter.com/GPUsAreMagic/status/1256866465577394181

Re: The x86 architecture is the weirdo, part 2

#165
post #90

Earlier quoted context omitted.

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 tha…

"always" is not the weird one -- that's just the same as everyone else. "Never" is weird, immediately spending 1/16th of the opcode space (256 million instructions) on NO-OPs. PC being a general-purpose register was historically not uncommon. PDP-11 and VAX both did it and they were kinda popular at one time. Load/store multiple was also fairly common with, for example, both 68000 and VAX having it. IBM 360 also, tho…

> "always" is not the weird one -- that's just the same as everyone else. "Never" is weird, immediately spending 1/16th of the opcode space (256 million instructions) on NO-OPs.

Worse, iirc what looks like it should be the slot for the "never" condition actually does exactly the same thing as "always".

Re: The x86 architecture is the weirdo, part 2

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

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.

Re: The x86 architecture is the weirdo, part 2

#167
post #38

Earlier quoted context omitted.

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

The C language and portable C programs do not in any way require a Von Neumann architecture. In fact with the modern trend for phone/tablet/desktop/server OSes to use W^X memory permissions they effectively mandate programs written in Harvard-compatible style even if they technically have code and data in the same address space.

Once instruction sets got features such as index (or base) registers and register indirect addressing (including stack addressing) instead of absolute addressing (including for indirect jumps/subroutine calls) there was no longer any need to support self-modifying code during execution of the program itself, and Von Neumann architecture is not required except for initial loading of the program code into memory by the OS.

I'd think most modern instruction sets are easily capable of running with code and data in truly different address spaces.

The only real difficulty is in loading constant data and especially constant tables from program space. Microcontroller ISAs such as AVR have special instructions for program space loads. Any ISA where the PC is a GPR (PDP-11, VAX, arm32) or that has an explicit PC-relative addressing mode (preferably indexed) such as 68000 make it easy to detect that a memory reference is PC-relative and do it in the program space instead of the data space.

Arm64 with ADR and ADRP and RISC-V with AUIPC make it tricky because hardware would have to track that a GPR contains a pointer derived from the PC. x86 and PowerPC make it even more difficult, because the only way to get the PC value is to do a fake function call to the next instruction (or to keep return stack prediction happy, to a real function that just saves the return address then returns). On these ISAs you're probably better off assembling all constants using load immediate and shifts, and arrays or tables of constants using computed jumps to load immediate instructions.

In short, using a conventional modern ISA with Harvard architecture is doable if you want to.

Re: The x86 architecture is the weirdo, part 2

#168

Earlier quoted context omitted.

"always" is not the weird one -- that's just the same as everyone else. "Never" is weird, immediately spending 1/16th of the opcode space (256 million instructions) on NO-OPs. PC being a general-purpose register was historically not uncommon. PDP-11 and VAX both did it and they were kinda popular at one time. Load/store multiple was also fairly common with, for example, both 68000 and VAX having it. IBM 360 also, tho…

> "always" is not the weird one -- that's just the same as everyone else. "Never" is weird, immediately spending 1/16th of the opcode space (256 million instructions) on NO-OPs. Worse, iirc what looks like it should be the slot for the "never" condition actually does exactly the same thing as "always".

Hmm. I guess I never actually tried it.

The A64 manual says 1111 on a Bcc etc disassembles as NV but does the same as AL.

The ARM7TDMI manual says 1111 is reserved and don't use it. I don't know the actual behaviour.

Aha. The Welsh&Knaggs "ARM Book" says before ARMv3 NV meant NV. In ARMv3 and ARMv4 NV is unpredictable. And in ARMv5 NV is used to encode "various additional instructions that can only be executed unconditionally".

Re: The x86 architecture is the weirdo, part 2

#169
post #49

Earlier quoted context omitted.

> ARM spends it on pc being wrong. Heh, having dealt with x86 for years, this is comparatively such a nothing burger. It's always a simple known fixed offset. > softfloat vs softfp vs hardfp vs vfp That's something not really unique to ARM per se. Any architecture with options for hardware FPU are going to practically need ABI specs for the soft and hard cases (you don't absolutely need anything more than hardfp sinc…

> Curious what you're referring to here - but I personally wouldn't consider assembly language dialects to be part of a CPU architecture. I assume they're talking about ARM vs. Thumb?

Belated, but no, I was referring to UAL vs old syntax.

Re: The x86 architecture is the weirdo, part 2

#170
post #13
post #10

Earlier quoted context omitted.

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.

Not sure if you'll see this - going through old tabs - but I was curious, and just in case: what are the practical differences between Xen and KVM here?
Post reply on HN