And my reaction is:
Originally posted by juarezr
View Post
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.
Originally posted by juarezr
View Post
- 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.
Leave a comment: