5 ms·

I think one less visible aspect of RISC is the more orthogonal instruction set. Consider a CISC instruction set with all kinds of exceptional cases requiring s

I think one less visible aspect of RISC is the more orthogonal instruction set. Consider a CISC instruction set with all kinds of exceptional cases requiring specific registers. Humans writing assembler won't care much. When code was written in higher level languages and compilers did more advanced optimizations, instruction sets had to adapt to this style: A more regular instruction set, more registers, and simpler ways to use each register with each instruction. This was also part of the RISC movement. Consider the 8086, eg with http://mlsite.net/8086/ http://mlsite.net/8086/ * Temporary results belong in AX,so note in rows 9 and A how some common instructions have shorter encodings if you use AL/AX as a register. * Counters belong in CX, so shift and rotation only work with CX. There is a specific JCXZ, jump if CX is zero, intended for loops. * Memory is pointed at with BX,SI,DI, the mod r/m byte simply has no encoding for the other registers. * There are instructions as XLAT or AAM that are almost impossible for a compiler to use. * Multiplication and division have AX:DX as implicit register pair for one operand. * Conditional jumps had a short range of +/- 128 bytes, jumping further required an unconditional jump. Starting from the 80386 32 bit mode, a lot of this was cleaned up and made better accessible for compilers: EAX EBX ECX EDX ESI EDI were more or less interchangeable. Multiplication, shifting and memory access became possible with all these registers. Conditional jumps could reach the whole address space. I heard people at the time describing the x86 instruction set as more RISC-like starting with the 80386.

lokedhs 5y ago
I think this is specific to x86, which is not the only CISC CPU. Other CISC architectures are much more regular. I'm familiar with M68k which is both regular and CISC. You then have others, like the PDP-10 and S370 which are also regular but doesn't have these register-specific requirements that the Intel CPU's are stuck with.
- hyperman1 5y ago
  True, the 8086 instruction set is ugly as hell. The 68000 was much better. I never saw the PDP-10 or S370 assembly , so I can't comment there. AFAIK it was a quick and dirty stopgap processor to drop in the 8080-shaped hole until they could finish the iapx432. Intel wanted 8080 code to be almost auto-translatable to 8086 code and give their customers a way out of the 8bit 64K world. So they designed instructions and a memory layout to make this possible, at the cost of orthogonality. Then IBM hacked together the quick and dirty PC based on the quick and dirty processor, and somehow one of the worst possible designs became the industry standard. Thinking of it, the 80386 might be Intel coming to terms with the fact that everyone was stuck with this ugly design, and making the best of it. See also the 80186, a CPU incompatible with the PC. Maybe a sign Intel didn't believed in the future of the PC ?
  - leeter 5y ago
    I think intel and IBM didn't expect the need for compatibility to be an issue. After all when the IBM PC was built generally speaking turning on and having a BASIC env was considered good enough. IBM added DOS so that CP/M customers would feel comfortable and it shows in PC-DOS 1.0. which is insanely bare bones. So it was not unreasonable for both IBM and Intel to assume that things like the PC-JR made sense, because backwards compatibility was the exception at that point not the rule. IBM in particular didn't take the PC market seriously and paid for it by getting their lunch eaten by the clones. It's the clones we have to thank for the situation we're in today. If Compaq hadn't done a viable clone and survived the lawsuit we'd probably be using something else (Amiga?). But they did and the rest is history, computing on IBM-PC compatible hardware became affordable and despite better alternatives (sometimes near equal cost) the PC won out.
  - monocasa 5y ago
    > See also the 80186, a CPU incompatible with the PC. Maybe a sign Intel didn't believed in the future of the PC ? The 80186 was already well in its design phase when the PC was developed. And the PC wasn't even what Intel thought a personal computer should look like; they were pushing the multibus based systems hard at the time with their iSBC line.

lokedhs 5y ago

I think this is specific to x86, which is not the only CISC CPU. Other CISC architectures are much more regular. I'm familiar with M68k which is both regular and CISC. You then have others, like the PDP-10 and S370 which are also regular but doesn't have these register-specific requirements that the Intel CPU's are stuck with.

hyperman1 5y ago
True, the 8086 instruction set is ugly as hell. The 68000 was much better. I never saw the PDP-10 or S370 assembly , so I can't comment there. AFAIK it was a quick and dirty stopgap processor to drop in the 8080-shaped hole until they could finish the iapx432. Intel wanted 8080 code to be almost auto-translatable to 8086 code and give their customers a way out of the 8bit 64K world. So they designed instructions and a memory layout to make this possible, at the cost of orthogonality. Then IBM hacked together the quick and dirty PC based on the quick and dirty processor, and somehow one of the worst possible designs became the industry standard. Thinking of it, the 80386 might be Intel coming to terms with the fact that everyone was stuck with this ugly design, and making the best of it. See also the 80186, a CPU incompatible with the PC. Maybe a sign Intel didn't believed in the future of the PC ?
- leeter 5y ago
  I think intel and IBM didn't expect the need for compatibility to be an issue. After all when the IBM PC was built generally speaking turning on and having a BASIC env was considered good enough. IBM added DOS so that CP/M customers would feel comfortable and it shows in PC-DOS 1.0. which is insanely bare bones. So it was not unreasonable for both IBM and Intel to assume that things like the PC-JR made sense, because backwards compatibility was the exception at that point not the rule. IBM in particular didn't take the PC market seriously and paid for it by getting their lunch eaten by the clones. It's the clones we have to thank for the situation we're in today. If Compaq hadn't done a viable clone and survived the lawsuit we'd probably be using something else (Amiga?). But they did and the rest is history, computing on IBM-PC compatible hardware became affordable and despite better alternatives (sometimes near equal cost) the PC won out.
- monocasa 5y ago
  > See also the 80186, a CPU incompatible with the PC. Maybe a sign Intel didn't believed in the future of the PC ? The 80186 was already well in its design phase when the PC was developed. And the PC wasn't even what Intel thought a personal computer should look like; they were pushing the multibus based systems hard at the time with their iSBC line.