Intel Reportedly Interested In Acquiring RISC-V Firm SiFive

[Guest]

Maybe, Intel trying to enter in the smartphone cpu market again.. Who knows?

Oooh, yes that would be interesting. RISC-V CPU device with fully open source drivers.

[bridgman]

....really??? If modern x86 is RISC then this potentially has everything to do with everything and would make the purchase or consideration of SiFive totally not moot.

Intel RISC internals; SiFive RISC patents. I don't see the correlation. You're right. It is totally moot.

OK, that's an interesting point... assuming I am stripping away the sarcasm correctly.

[bridgman]

a Stack machine style processor (push/pop) regarding memory

however, Intel evolved x86 to a register machine style for performance reasons
this was done by establishing conventions on how to write x86 assembly to access virtual/fake register besides the few original basic ones

At the risk of nitpicking, I don't think the existence of push/pop instructions (or the PDP11/68xxx equivalent of auto-increment indirect addressing modes) is enough to define an architecture as a stack machine. That would normally involve not having general purpose registers at all - just stack pointer, program counter and maybe condition code register.

My recollection is that when you run across a real stack machine (Burroughs mainframes were my first encounter) it's really obvious because the primary addressing mode is stack-relative at ISA level, more like programming an old HP calculator in RPN than programming a typical register-oriented CPU.

Interestingly enough I believe the x87 coprocessors *were* stack machines, with no architecturally visible registers - just a stack. I believe that stack was replaced by explicitly addressable registers in later iterations. Maybe that's what you were thinking of re: transition from stack to register oriented programming ?

[Viki Ai]

That's a funny way of saying "x86 is CISC, not RISC"

Its an ancient (by now) misnomer, based on the fact that microcode engines, such as the ones driving various x86 instruction sets, have, and have always had, a small convergent overlap with a couple of RISC-like concepts.

Back here in reality, the microcode engine inside a Core (or 680x0, or....) processor is RISC-like in the same way that a petrol lawnmower engine is like the electric motor in an industrial vacuum cleaner: both have chunky metallic parts of a somewhat cylindrical shape and use energy to spin blades in a circle, because ... how else would you design such things?! But they are certainly not even remotely the same thing!

[juarezr]

At the risk of nitpicking, I don't think the existence of push/pop instructions (or the PDP11/68xxx equivalent of auto-increment indirect addressing modes) is enough to define an architecture as a stack machine. That would normally involve not having general purpose registers at all - just stack pointer, program counter and maybe condition code register.

My recollection is that when you run across a real stack machine (Burroughs mainframes were my first encounter) it's really obvious because the primary addressing mode is stack-relative at ISA level, more like programming an old HP calculator in RPN than programming a typical register-oriented CPU.

Interestingly enough I believe the x87 coprocessors *were* stack machines, with no architecturally visible registers - just a stack. I believe that stack was replaced by explicitly addressable registers in later iterations. Maybe that's what you were thinking of re: transition from stack to register oriented programming ?

1. I meant "Stack machine style" was a very high level analogy for explaining that a programmer would need to use often the memory/stack for storing local variables in x86.

2. Regarding the stack-register transition above it was register renaming.

[bridgman]

1. I meant "Stack machine style" was a very high level analogy for explaining that a programmer would need to use often the memory/stack for storing local variables in x86.

OK, so I guess you are talking about x86 having fewer architectural registers than RISC-V then (16 integer registers for x86-64, 32 for RISC-V RV32I) ?

You may disagree with my choice of x86-64 (with 16 registers vs 8 for earlier x86 versions) but I would argue that it has been the standard at a hardware level for ~20 years now and that use of 64-bit executables is more common than 32-bit these days.

I'm not saying that having fewer architectural registers no longer matters, but once you implement sufficiently capable cache and load/store logic the execution cost of a small number of additional memory writes and reads (when the compiler runs out of registers) is quite low, since the variables are effectively spilling to cache rather than to memory.

My impression is that the architectural advantage of RISC instruction sets is most visible in lower-end CPUs (with simpler cache and load/store logic) and that even the CPUs found in typical phones these days have moved past that point. Having a large number of architectural registers still makes a difference, but I would argue that the difference is much smaller today than it was in the early days of RISC - partly due to improvements in cache and load-store logic and partly due to typical x86 CPUs having 16 architectural registers rather than the original 8.

establishing conventions on how to write x86 assembly to access virtual/fake register besides the few original basic ones

2. Regarding the stack-register transition above it was register renaming.

Ahh, OK... I wasn't sure exactly what you meant there.

That said, I would argue that register renaming is used on chips with a RISC ISA to a similar extent as on chips with a CISC ISA, at least for high-performance designs, and that once you get into out-of-order execution you need register renaming.

If you look at high performance ARM and RISC-V designs they all appear to use register renaming as well. As an example the BOOM (Berkeley Out-of-Order Machine) and SiFive U8 family both use register renaming, as do the high performance ARM designs. As an example, the BOOM RISC-V micro-architecture uses 128 physical registers for integer and another 128 for float:

https://docs.boom-core.org/en/latest...view/boom.html

EDIT - something was nagging at me about this - register renaming is not visible to the execution model, so I'm not sure how to interpret your original comment since AFAIK there is nothing you can do at assembly level to take advantage of register renaming:

[wizard69]

Hot take: the world would be a better place if companies simply could not buy other companies. It should be seen as an anti-trust violation.

That is all fine until yo are running a company that needs capital to expand. Sometimes being bought assures your continued existence. I really don't see SiFive having a chance in hell currently so maybe this will assure SiFive stays around. Given that I suspect everybody would be better off if AMD came up with a better counter offer.

[microcode]

AFAIK there is nothing you can do at assembly level to take advantage of register renaming:

I think you can give renaming/reordering an easier time by keeping the contention on a given architectural register lower; but with how large this part is in today's high performance designs, maybe it has long since ceased to matter.

[bridgman]

I think you can give renaming/reordering an easier time by keeping the contention on a given architectural register lower; but with how large this part is in today's high performance designs, maybe it has long since ceased to matter.

Agree that any change you make in register usage will impact register renaming, but I don't think any of those changes give you the illusion or benefit of "more registers" other than allowing the core to execute instructions out of order (which is where renaming comes in normally).

There are programming models which expose additional registers via bank switching without requiring wider register select fields in the ISA but I don't remember ever seeing them used on x86 designs.

[DrYak]

I've been programming in assembler when I was a teen back in the 286/386/486 days.
And my reaction is:

a CISC ISA regarding programmer, compiler, or assembler interface
a Stack machine style processor (push/pop) regarding memory

Whaaaa.....????
Nope. No, no, no. x86 is (alsmot) not a stack-machine.

The mere existence of push/pop instruction doesn't make a stack-machine. (In fact RISC processors also tend to have a stuck). A stack is a generic tool to save state and optionnally pass parameters as you call into a function. (Though it's not the only one: a lot of calling convention can also pass parameters around in registers, that's e.g. the convention with x86_64, and some RISC architecture contain multiple register files, and save state simply by switching register sets around).

x86 as well as all RISC are register machines as they can combine *any arbitrary register* when doing operations. When doing A = A + B, A and B could be anything.
(well, almost. Not entirely true: the earlier 8086 and 8088 have some limitations, e.g.: AX tended to have a special role, SI and DI are mostly used as pointers, and some instruction couldn't use some combos. But by the time 386 was out most of "fixed combo" opcode had also alternate allowing arbitrary operands.
Motorola 68000 similarly had some limitation: separate address and data register, but any data register can arbitrarily be chosen for any operation.
RISC allow arbiratry register use as this is part of the core philosophy of the design).

The only stack-machine like architecture found in the x86 real was the older x87 family of maths co-processors.
A real stack machine doesn't have individually addressable registers. Instead it has *only* a stack.
Every instructions works by taking specifically 1, 2 or more argument from the top of the stack, does its computation and pushes back the results on the stack.
Push and pop are only used to put values on the stack for the individual machine instructions to consume when computing, instructions themselves are purely restrict to the N top-most elements of the stack they can't operate on any arbitrary element. When doing A = A + B, A is ob the top of the stack, B is the next element on the stack and is destroyed in the process..
That's roughly how old maths x87 co-processors worked for Intel: they had a stack of 8 floating point registers.
(Though Intel cheated a bit and departed from a pure stack architecture: some operation (Addition, Multiplication, etc.) accept that the second operand isn't necessarily the 2nd element on top of the stack but could be fished deeper, and they allowed shuffling around the stack. So in real-life x87 offered a bit more flexibility than a true stack machine).
(On later math coprocessors (the one embed inside Pentium), this was further optimized: the instruction set looks like a stack, but under the hood it is an actual register machine and uses clever register renaming. FXCH doesn't really shuffle the stack around and comes for free: it's just a roundabout way to say which register the next instruction should work on)

What contrast Intel with load-store architecture is the way they interact with memory:
- load-store architecture only support that: loading from memory and storing to memory. To do anything else beside that requires first loading stuff from memory into registers, then doing any computation instruction that pleases you solely on any arbitrary register, then store the final result back to memory. load stuff, do your maths, store stuff. Hence "load-store".
- Intel-style CISC support combining memory operand when executing instruction. You can add a value stored in memory to your register, you can substract a register's value from a cell in memory, etc.

however, Intel evolved x86 to a register machine style for performance reasons

Intel didn't really "evolve to" a register machine.
- Intel has on one hand the x86 that goes back all the way to the 8088 and 8086 with a large number of new features bolted on top (and the inner architecture under the hood redone a couple of time along the way, but still working on the same, constantly expanded, instruction set), which in turn where a quick hack to bring a successor to the previous 8008, 8080, 8085 (and if you squint at it, the ISA are close-ish enough together to quickly make ports of software producting while assisted by tools), as an answer to the new/better/bigger offerings coming from competitors (e.g.: the 16/32bit 68k from Motorola successing their older 8bit 6800)
- Intel had big dreams for a completely different and independent iAXP 432 which was planned as a giant leap beyond what 8bit CPU offered (a mainframe on a chip !), but ended up a big pile of delays and a flop.

They are two different branches, the stack-based one never managed to take off at all.