5 ms·

> I don't quite understand the objection here, this is fairly elegant in my opinion, you have a single opcode used to encode several operations by using "specia

> I don't quite understand the objection here, this is fairly elegant in my opinion, you have a single opcode used to encode several operations by using "special cases". Sounds like CISC.

pjc50 8y ago
But why does anyone care where the boundary is drawn, especially based on entirely subjective opinions about whether one thing is more complex than another?
simias 8y ago
I don't understand how you reach this conclusion, if anything it's the opposite of CISC: instead of having highly specialized instructions you have a single generic instruction that can be used in all sorts of context. Note that this is very different from x86 "overloaded" encoding where a single mnemonic can have a million different encodings doing wildly different things depending on the operands, prefixes, lunar phase and/or operating mode[1], in this case there's no additional complexity to the "OR" implementation besides the adjunction of an R0 register (which is not specific to this opcode). You can still describe the encoding and functionality in a single line[2]. [1] https://svkt.org/~simias/up/20180926-112325_x86-mov.png https://svkt.org/~simias/up/20180926-112325_x86-mov.png [2] https://svkt.org/~simias/up/20180926-112224_or-encoding.png https://svkt.org/~simias/up/20180926-112224_or-encoding.png
bonzini 8y ago
No, it's very different. CISC has different encodings for MOV and OR (and often subtle differences, e.g. OR updates the flags and MOV doesn't). On RISC processors, which have MOV as a special case of OR, the assembler accepts MOV at the source code level but the processor does not have to implement a separate MOV instruction at the binary level. Therefore the instruction set is indeed reduced. ARM's peculiarity is that the fundamental ALU operation is "R1 op (R2 shiftop R3)" or "R1 op (R2 shiftop #nn". But it's still not a CISC design, it's just that the barrel shifter is at a different place in the ALU and that shows in the instruction encoding. Apart from this quirk the ideas from the previous paragraph apply just as well to ARM.
kccqzy 8y ago
I don't think this characterizes an instruction set as CISC at all. In any case, having those "special cases" means that if an operation can be subsumed by another operation, the former is just an alias of the latter on the instruction encoding level, thereby reducing the actual number of instructions. Think of it as syntactic sugar. I still find this classic to be the best explanation of the technical characteristics of CISC/RISC: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html Here's a short summary: Most RISCs: - Have 1 size of instruction in an instruction stream - And that size is 4 bytes - Have a handful (1-4) addressing modes - Have NO indirect addressing in any form (i.e., where you need one memory access to get the address of another operand in memory) - Have NO operations that combine load/store with arithmetic, i.e., like add from memory, or add to memory. - Have no more than 1 memory-addressed operand per instruction - Do NOT support arbitrary alignment of data for loads/stores - Use an MMU for a data address no more than once per instruction - Have >= 5 bits per integer register specifier - Have >= 4 bits per FP register specifier
- Symmetry 8y ago
  Yes, but by that classic definition ARM is certainly one of the CISCiest of the RISC architectures with its condition codes, barrel shifter, auto-increment loads and stores, and load/store multiple. And x86 is one of the RISCiest of the CISCs with its lack of indirect memory access. All of which might represent a sort of semantic happy medium.
- simias 8y ago
  IMO RISC is more a philosophy than a technical term, your definition is something that was created post-facto to try and come with a definition. It's more like "all currently accepted RISC IAs have the following characteristics" but I disagree that they're an appropriate definition. For instance: >Have 1 size of instruction in an instruction stream and that size if 4 bytes So that means that Thumb isn't RISC because it has 16 bits instructions and a few double-width opcodes? Even though its instruction set if effectively even more restricted than ARM? That doesn't make sense to me. >Do NOT support arbitrary alignment of data for loads/stores MIPS has SWL/SWR LWL/LWR, does that count? I suppose you could say that RISC has no support for arbitrary alignment in regular load and store instructions but again, is that really enough to disqualify an IA? What if I made a tweaked MIPS CPU with an identical instruction set with the only difference being that unaligned LW/SW would work as intended instead of raising an exception, would it stop being RISC? >Have >= 5 bits per integer register specifier, Have >= 4 bits per FP register specifier That actually disqualifies ARM32 as far as I can tell, since it only has 16GPRs encoded using 4 bits. I fail to see how this small encoding detail is relevant to RISC anyway. Maybe it just meas that you need at least 32GPRs? Wikipedia has a much broader (and IMO more reasonable) definition of RISC: >Various suggestions have been made regarding a precise definition of RISC, but the general concept is that such a computer has a small set of simple and general instructions, rather than a large set of complex and specialized instructions. By this definition an instruction such as "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" is very much un-risc-y.
jlouis 8y ago
The basic idea of RISC was to reduce the complexity of individual instructions. Rather than having one instruction, you had several, but each of those would be easier to decode and execute. And, as history has shown, it was also quite a bit faster to execute such simplified instructions. Hence, assembling a single mnemonic into two or more instructions is fairly common on RISC architectures. But the instruction set at the machine level is still simple and direct, even if the assembler expands. As a fun fact, modern x86 will often just microcode complex instructions inside the CPU to several simple mu-ops and then execute those. In turn, they are just doing the same work as the assembler, but in hardware. It is necessary for backwards compatibility, but it is hardly elegant.
masklinn 8y ago
It sounds like the exact opposite: you're reducing the actual instruction set, just providing convenient shorthands for common cases at the assembly level.

> I don't quite understand the objection here, this is fairly elegant in my opinion, you have a single opcode used to encode several operations by using "special cases". Sounds like CISC.

pjc50 8y ago

But why does anyone care where the boundary is drawn, especially based on entirely subjective opinions about whether one thing is more complex than another?

simias 8y ago

I don't understand how you reach this conclusion, if anything it's the opposite of CISC: instead of having highly specialized instructions you have a single generic instruction that can be used in all sorts of context. Note that this is very different from x86 "overloaded" encoding where a single mnemonic can have a million different encodings doing wildly different things depending on the operands, prefixes, lunar phase and/or operating mode[1], in this case there's no additional complexity to the "OR" implementation besides the adjunction of an R0 register (which is not specific to this opcode). You can still describe the encoding and functionality in a single line[2]. [1] https://svkt.org/~simias/up/20180926-112325_x86-mov.png https://svkt.org/~simias/up/20180926-112325_x86-mov.png [2] https://svkt.org/~simias/up/20180926-112224_or-encoding.png https://svkt.org/~simias/up/20180926-112224_or-encoding.png

bonzini 8y ago

No, it's very different. CISC has different encodings for MOV and OR (and often subtle differences, e.g. OR updates the flags and MOV doesn't). On RISC processors, which have MOV as a special case of OR, the assembler accepts MOV at the source code level but the processor does not have to implement a separate MOV instruction at the binary level. Therefore the instruction set is indeed reduced. ARM's peculiarity is that the fundamental ALU operation is "R1 op (R2 shiftop R3)" or "R1 op (R2 shiftop #nn". But it's still not a CISC design, it's just that the barrel shifter is at a different place in the ALU and that shows in the instruction encoding. Apart from this quirk the ideas from the previous paragraph apply just as well to ARM.

kccqzy 8y ago

I don't think this characterizes an instruction set as CISC at all. In any case, having those "special cases" means that if an operation can be subsumed by another operation, the former is just an alias of the latter on the instruction encoding level, thereby reducing the actual number of instructions. Think of it as syntactic sugar. I still find this classic to be the best explanation of the technical characteristics of CISC/RISC: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html Here's a short summary: Most RISCs: - Have 1 size of instruction in an instruction stream - And that size is 4 bytes - Have a handful (1-4) addressing modes - Have NO indirect addressing in any form (i.e., where you need one memory access to get the address of another operand in memory) - Have NO operations that combine load/store with arithmetic, i.e., like add from memory, or add to memory. - Have no more than 1 memory-addressed operand per instruction - Do NOT support arbitrary alignment of data for loads/stores - Use an MMU for a data address no more than once per instruction - Have >= 5 bits per integer register specifier - Have >= 4 bits per FP register specifier

Symmetry 8y ago
Yes, but by that classic definition ARM is certainly one of the CISCiest of the RISC architectures with its condition codes, barrel shifter, auto-increment loads and stores, and load/store multiple. And x86 is one of the RISCiest of the CISCs with its lack of indirect memory access. All of which might represent a sort of semantic happy medium.
simias 8y ago
IMO RISC is more a philosophy than a technical term, your definition is something that was created post-facto to try and come with a definition. It's more like "all currently accepted RISC IAs have the following characteristics" but I disagree that they're an appropriate definition. For instance: >Have 1 size of instruction in an instruction stream and that size if 4 bytes So that means that Thumb isn't RISC because it has 16 bits instructions and a few double-width opcodes? Even though its instruction set if effectively even more restricted than ARM? That doesn't make sense to me. >Do NOT support arbitrary alignment of data for loads/stores MIPS has SWL/SWR LWL/LWR, does that count? I suppose you could say that RISC has no support for arbitrary alignment in regular load and store instructions but again, is that really enough to disqualify an IA? What if I made a tweaked MIPS CPU with an identical instruction set with the only difference being that unaligned LW/SW would work as intended instead of raising an exception, would it stop being RISC? >Have >= 5 bits per integer register specifier, Have >= 4 bits per FP register specifier That actually disqualifies ARM32 as far as I can tell, since it only has 16GPRs encoded using 4 bits. I fail to see how this small encoding detail is relevant to RISC anyway. Maybe it just meas that you need at least 32GPRs? Wikipedia has a much broader (and IMO more reasonable) definition of RISC: >Various suggestions have been made regarding a precise definition of RISC, but the general concept is that such a computer has a small set of simple and general instructions, rather than a large set of complex and specialized instructions. By this definition an instruction such as "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" is very much un-risc-y.

jlouis 8y ago

The basic idea of RISC was to reduce the complexity of individual instructions. Rather than having one instruction, you had several, but each of those would be easier to decode and execute. And, as history has shown, it was also quite a bit faster to execute such simplified instructions. Hence, assembling a single mnemonic into two or more instructions is fairly common on RISC architectures. But the instruction set at the machine level is still simple and direct, even if the assembler expands. As a fun fact, modern x86 will often just microcode complex instructions inside the CPU to several simple mu-ops and then execute those. In turn, they are just doing the same work as the assembler, but in hardware. It is necessary for backwards compatibility, but it is hardly elegant.

masklinn 8y ago

It sounds like the exact opposite: you're reducing the actual instruction set, just providing convenient shorthands for common cases at the assembly level.