4 ms·

CISC has always been much nicer to hard write assembly code in than RISC is. The only reason RISC was able to take off was that most code started to be generat

CISC has always been much nicer to hard write assembly code in than RISC is. The only reason RISC was able to take off was that most code started to be generated by compilers rather than through assemblers. Given the advance of modern computer architecture that the author talks about many of the old advantages of RISC no longer apply. If you're going to be doing out of order execution the the extra effort in implementing some extra instructions really isn't important for application processors. The big advantage that RISC has these days is that fixed width instructions are easy on the decoder. You can also have variable width instruction that use UTF8esque byte marking to make things easier on the decoder but x86 doesn't have anything like that. But then again separating them entirely in the ISA makes thing easier on the designers. Oh, and it's a bad idea to touch memory multiple times in a single instruction on a modern machine but Intel's optimization manuals warn you not to do that and compilers abide by those warnings. If you want an ISA feature that's really hard to design into a high performance uArch then there's indirect addressing but unlike most CISC ISAs x86 managed to avoid that one. The advantages of RISC might be overblown in some sense, but there have been a lot of new instruction set architectures developed over the last 20 years when the RISC/CISC debates were raging. Many of those have been weird in various ways but almost all look a lot more like RISC instruction sets than CISC instruction sets and it's not just because people are following the herd. And I've got the sense that my inside view of the issue is underestimating now advantageous RISCishness is. When ARM had the opportunity to redesign their ISA when the transitioned to 64 bits they simplified their ISA quite a bit and increased the number of registers from 16 to 32, basically making their ISA much more similar to a classical RISC design. I don't really understand why they thought that going that way was an advantage but it seems like people actually involved with designing these things instead of just thinking about them in their armchairs still think that RISC has a lot of advantages.

yokohummer7 11y ago
> The big advantage that RISC has these days is that fixed width instructions are easy on the decoder. One thing that I've wondered is how much more efforts are needed to decode variable-width instructions. Decoding itself sounds fairly easy (but frankly I don't know any details), to the point that the amount of time needed for loading/storing/calculating overwhelms that of decoding. But decoding should happen extremely fast to fill the pipeline, so the speed might still matter. Can decoding instructions be an actual bottleneck?
- cesarb 11y ago
  > Can decoding instructions be an actual bottleneck? Yes. We have processors which can execute 4 or more instructions in parallel (if I'm reading http://www.anandtech.com/show/6355/intels-haswell-architecture/8 http://www.anandtech.com/show/6355/intels-haswell-architectu... right, the processor I'm using to type this message can start the execution of up to 8 microinstructions in parallel). You need to decode the instructions fast enough to keep up. Since the clock is the same, you basically need several decoders in parallel. But with variable-length instructions, you have to know the length of the first instruction so the second decoder knows where to start; you have to know the length of both instructions so the third decoder knows where to start; and so on. The x86 architecture is a worst-case of a variable-length architecture: take a look at http://wiki.osdev.org/X86-64_Instruction_Encoding http://wiki.osdev.org/X86-64_Instruction_Encoding and think how you would determine the length of an arbitrary instruction. High-performance x86 implementations have to do all kinds of crazy tricks. An extra pipeline stage solely to figure out the instruction lengths (see http://www.anandtech.com/show/6355/intels-haswell-architecture/6 http://www.anandtech.com/show/6355/intels-haswell-architectu...), extra tags in the instruction cache to mark the instruction boundaries, decoding the instruction lengths while loading the instruction cache, caching already decoded instructions, and so on. Contrast this with for instance RISC-V with the compressed instructions extension, where you have to examine just two bits on each instruction to figure out if it's a 32-bit or a 16-bit instruction. I'd have to look up the encoding for Thumb-2, but I'd expect it to be something equally simple. Make it simple enough, and you might be able to split the instructions and decode them in the same pipeline stage.
  - userbinator 11y ago
    The x86 architecture is a worst-case of a variable-length architecture I'm guessing you haven't seen VAX. The first byte isn't even organised in any discernable pattern so there are both rare and very common instructions there, and operands are specified using a very flexible system that makes length decoding far more difficult than x86. In contrast, x86 has a mostly consistent 2-3-3 octal-based encoding, and having the first 2-3 bytes is usually enough to decode the instruction's length: http://reocities.com/SiliconValley/heights/7052/opcode.txt http://reocities.com/SiliconValley/heights/7052/opcode.txt
duaneb 11y ago
> CISC has always been much nicer to hard write assembly code in than RISC is. I don't see this. Do you have any examples? x86 was only "nicer" for the first 10 hours of assembly—and if you're writing your own (dis)assembler, it's about 10x harder than any risc. It's also much harder to compute cycle time, which is the only reason I can think of to be staring at assembly for multiple hours (as opposed to e.g. c). It's also much harder to get "good" at x86, and it mostly consists of learning the subset of x86 that is actually optimized in the way you might expect. The vast majority of instructions you shouldn't be using at all.
- dietrichepp 11y ago
  x86 was designed back when people wrote significant chunks of code in assembly not because they wanted to shave some time off a critical subroutine, but because they didn't even have a compiler. Under those conditions, I'd rather have x86 than PowerPC or ARM, it's just less typing.
  - duaneb 11y ago
    While this is true, that form of coding is... dead. It doesn't produce better compilation backends—if you're working with strings, chances are the compiler will ignore most of the string instructions but LODS/LODSB/LODSW/LODSD.

yokohummer7 11y ago

> The big advantage that RISC has these days is that fixed width instructions are easy on the decoder. One thing that I've wondered is how much more efforts are needed to decode variable-width instructions. Decoding itself sounds fairly easy (but frankly I don't know any details), to the point that the amount of time needed for loading/storing/calculating overwhelms that of decoding. But decoding should happen extremely fast to fill the pipeline, so the speed might still matter. Can decoding instructions be an actual bottleneck?

cesarb 11y ago
> Can decoding instructions be an actual bottleneck? Yes. We have processors which can execute 4 or more instructions in parallel (if I'm reading http://www.anandtech.com/show/6355/intels-haswell-architecture/8 http://www.anandtech.com/show/6355/intels-haswell-architectu... right, the processor I'm using to type this message can start the execution of up to 8 microinstructions in parallel). You need to decode the instructions fast enough to keep up. Since the clock is the same, you basically need several decoders in parallel. But with variable-length instructions, you have to know the length of the first instruction so the second decoder knows where to start; you have to know the length of both instructions so the third decoder knows where to start; and so on. The x86 architecture is a worst-case of a variable-length architecture: take a look at http://wiki.osdev.org/X86-64_Instruction_Encoding http://wiki.osdev.org/X86-64_Instruction_Encoding and think how you would determine the length of an arbitrary instruction. High-performance x86 implementations have to do all kinds of crazy tricks. An extra pipeline stage solely to figure out the instruction lengths (see http://www.anandtech.com/show/6355/intels-haswell-architecture/6 http://www.anandtech.com/show/6355/intels-haswell-architectu...), extra tags in the instruction cache to mark the instruction boundaries, decoding the instruction lengths while loading the instruction cache, caching already decoded instructions, and so on. Contrast this with for instance RISC-V with the compressed instructions extension, where you have to examine just two bits on each instruction to figure out if it's a 32-bit or a 16-bit instruction. I'd have to look up the encoding for Thumb-2, but I'd expect it to be something equally simple. Make it simple enough, and you might be able to split the instructions and decode them in the same pipeline stage.
- userbinator 11y ago
  The x86 architecture is a worst-case of a variable-length architecture I'm guessing you haven't seen VAX. The first byte isn't even organised in any discernable pattern so there are both rare and very common instructions there, and operands are specified using a very flexible system that makes length decoding far more difficult than x86. In contrast, x86 has a mostly consistent 2-3-3 octal-based encoding, and having the first 2-3 bytes is usually enough to decode the instruction's length: http://reocities.com/SiliconValley/heights/7052/opcode.txt http://reocities.com/SiliconValley/heights/7052/opcode.txt

duaneb 11y ago

> CISC has always been much nicer to hard write assembly code in than RISC is. I don't see this. Do you have any examples? x86 was only "nicer" for the first 10 hours of assembly—and if you're writing your own (dis)assembler, it's about 10x harder than any risc. It's also much harder to compute cycle time, which is the only reason I can think of to be staring at assembly for multiple hours (as opposed to e.g. c). It's also much harder to get "good" at x86, and it mostly consists of learning the subset of x86 that is actually optimized in the way you might expect. The vast majority of instructions you shouldn't be using at all.

dietrichepp 11y ago
x86 was designed back when people wrote significant chunks of code in assembly not because they wanted to shave some time off a critical subroutine, but because they didn't even have a compiler. Under those conditions, I'd rather have x86 than PowerPC or ARM, it's just less typing.
- duaneb 11y ago
  While this is true, that form of coding is... dead. It doesn't produce better compilation backends—if you're working with strings, chances are the compiler will ignore most of the string instructions but LODS/LODSB/LODSW/LODSD.