5 ms·

Is having hardware acceleration for AES and SHA256 really a "CISC quirk", or just a really specialized set of arithmetic instructions? The classic RISC idea of

by pjscott 14y ago

Is having hardware acceleration for AES and SHA256 really a "CISC quirk", or just a really specialized set of arithmetic instructions? The classic RISC idea of making the core simple and fast doesn't really apply here; internally, it's all simple micro-operations driving special-purpose hardware. It seems similar to having a fused multiply-accumulate operation: they've figured out how to accelerate the core of a common task, and this is the API they've decided to give it.

enos_feedler 14y ago
most likely for energy-efficiency reasons.
simcop2387 14y ago
That's actually an almost reasonable definition of CISC for laypeople. Take a look at the definition on wikipedia. A complex instruction set computer (CISC, play /ˈsɪsk/) is a computer where single instructions can execute several low-level operations (such as a load from memory, an arithmetic operation, and a memory store) and/or are capable of multi-step operations or addressing modes within single instructions. Now the reality is that on the whole things are not quite as cut and dry. In this case they're doing it to give access to dedicated hardware for power gains most likely, which is why something that's typically close to RISC would add something like that. As time has gone on, both CISC and RISC systems have moved more toward a blend of both in-order to get the best of both worlds, from what i've heard interally most x86 chips actually work like a risc chip they just translate between things in the instruction decoder.
- anamax 14y ago
  > A complex instruction set computer (CISC, play /ˈsɪsk/) > is a computer where single instructions ... and/or are > capable of multi-step operations ... within single > instructions. What's a "multi-step operation"? I ask because I worked on the microarchitecture (read "implementation") of a microprocessor that had what was generally regarded as a very RISC instruction set. Yet, almost every instruction had multiple steps. Yes, including integer add. Were we doing something wrong? And no, "one cycle fundamental operations" doesn't change things. Dividing things into cycles is a design choice. For example, one might reasonably do integer adds in two steps.
  - sliverstorm 14y ago
    It's a fuzzy distinction, but it becomes more clear if you look at the x86 instruction set and its extensions. A very RISC chip usually just has ADD, OR, AND, LOAD, STORE, etc. But in x86 (CISC) we have things like these: UNPCKLPS: (sse1) Unpack and Interleave Low Packed Single-FP Values MOVSHDUP: (sse3) Move Packed Single-FP High and Duplicate AAM: ASCII Adjust AX After Multiply
    - anamax 14y ago
      If those ops are register-register, how are they necessarily not-RISC? Yes, division is inherently more complex than bitwise NAND, but it's not obvious to me where the line is that you find so clear. FWIW, I've seen a very serious architecture proposal that used two instructions for memory-reads. (It had one instruction for memory writes.) Along those lines, register-value fetch can be moved into a separate instruction....
      - deleted 14y ago
        [deleted]
      - sliverstorm 14y ago
        The sse1 instruction provide the option of register-register, but also support register-memory. I didn't realize it supported register-register mode, so now I see why it would be less obvious to you.
        anamax 14y ago
        Why is copying a value from register to memory (or memory to register) "RISC" while performing some logical operation to the value to the value as moves "not risc"? I'd agree that memory to memory is "not risc", but given the amount of work necessary to do a register access, it's unclear why doing work on a value is "not risc". Datapaths are NOT the complex part of a microprocessor.
  - waterhouse 14y ago
    Mmm, I think RISC has to be a relative term. (It does, after all, have "reduced" in its name, which implies a comparison with a less-reduced alternative.) So every time processor A has an instruction that can only be done with a sequence of several instructions on processor B, that is evidence that B is more RISCy than A.
wmf 14y ago
One definition of RISC is that every instruction should take one cycle and thus any instruction that takes longer is CISC. This led to MIPS not having multiply, for example. A different definition is that RISC should not have any instructions that could be just as efficiently broken into multiple simpler general-purpose instructions. For example, a memory-register architecture can do a load-and-add in one instruction but RISC prefers separate load and add instructions that take the same time. In this view AES instructions are justified as RISC because implementing an AES round with multiple simple instructions is much slower (6x in Intel's case).
- duaneb 14y ago
  > One definition of RISC is that every instruction should take one cycle and thus any instruction that takes longer is CISC. This led to MIPS not having multiply, for example. Err, if that was ever really a "RISC" thing, it got dropped quickly. I'm not even sure it's possible to create a sane architecture that runs one cycle per instruction: you need two clock edges just to load and store data from registers, let alone operating on the data. However, optimizing the pipeline so instructions are effectively one cycle makes sense; only one memory cycle per instruction makes sense. Making AES and SHA instructions doesn't really cohere to any definition of RISC I've ever seen: mostly, use as few instructions as possible because you don't have many opcodes to work with in fixed-size instructions. However, I'm also not opposed to these instructions through some dogmatic belief: I think encryption is important enough these days to be optimized to the greatest possible extent without sacrificing general purpose functionality.
  - brigade 14y ago
    The RISC vs CISC debate has been dead for years. Doubly so ever since we found the limits of scaling clock frequencies ever higher. After all, the RISC movement started as a reaction to the difficulties of scaling the architectures of the day to faster clock frequencies. Now (decades, really) CPU designers are concentrating on doing more work per clock cycle, which is rather anti-RISC. So the only questions that matter are "can we implement this feature efficiently?" and "does this feature provide enough performance or power gain for the implementation cost?"
duaneb 14y ago
You just described a CISC op.

by pjscott 14y ago

enos_feedler 14y ago

most likely for energy-efficiency reasons.

simcop2387 14y ago

That's actually an almost reasonable definition of CISC for laypeople. Take a look at the definition on wikipedia. A complex instruction set computer (CISC, play /ˈsɪsk/) is a computer where single instructions can execute several low-level operations (such as a load from memory, an arithmetic operation, and a memory store) and/or are capable of multi-step operations or addressing modes within single instructions. Now the reality is that on the whole things are not quite as cut and dry. In this case they're doing it to give access to dedicated hardware for power gains most likely, which is why something that's typically close to RISC would add something like that. As time has gone on, both CISC and RISC systems have moved more toward a blend of both in-order to get the best of both worlds, from what i've heard interally most x86 chips actually work like a risc chip they just translate between things in the instruction decoder.

anamax 14y ago
> A complex instruction set computer (CISC, play /ˈsɪsk/) > is a computer where single instructions ... and/or are > capable of multi-step operations ... within single > instructions. What's a "multi-step operation"? I ask because I worked on the microarchitecture (read "implementation") of a microprocessor that had what was generally regarded as a very RISC instruction set. Yet, almost every instruction had multiple steps. Yes, including integer add. Were we doing something wrong? And no, "one cycle fundamental operations" doesn't change things. Dividing things into cycles is a design choice. For example, one might reasonably do integer adds in two steps.
- sliverstorm 14y ago
  It's a fuzzy distinction, but it becomes more clear if you look at the x86 instruction set and its extensions. A very RISC chip usually just has ADD, OR, AND, LOAD, STORE, etc. But in x86 (CISC) we have things like these: UNPCKLPS: (sse1) Unpack and Interleave Low Packed Single-FP Values MOVSHDUP: (sse3) Move Packed Single-FP High and Duplicate AAM: ASCII Adjust AX After Multiply
  - anamax 14y ago
    If those ops are register-register, how are they necessarily not-RISC? Yes, division is inherently more complex than bitwise NAND, but it's not obvious to me where the line is that you find so clear. FWIW, I've seen a very serious architecture proposal that used two instructions for memory-reads. (It had one instruction for memory writes.) Along those lines, register-value fetch can be moved into a separate instruction....
    - deleted 14y ago
      [deleted]
    - sliverstorm 14y ago
      The sse1 instruction provide the option of register-register, but also support register-memory. I didn't realize it supported register-register mode, so now I see why it would be less obvious to you.
      - anamax 14y ago
        Why is copying a value from register to memory (or memory to register) "RISC" while performing some logical operation to the value to the value as moves "not risc"? I'd agree that memory to memory is "not risc", but given the amount of work necessary to do a register access, it's unclear why doing work on a value is "not risc". Datapaths are NOT the complex part of a microprocessor.
- waterhouse 14y ago
  Mmm, I think RISC has to be a relative term. (It does, after all, have "reduced" in its name, which implies a comparison with a less-reduced alternative.) So every time processor A has an instruction that can only be done with a sequence of several instructions on processor B, that is evidence that B is more RISCy than A.

wmf 14y ago

One definition of RISC is that every instruction should take one cycle and thus any instruction that takes longer is CISC. This led to MIPS not having multiply, for example. A different definition is that RISC should not have any instructions that could be just as efficiently broken into multiple simpler general-purpose instructions. For example, a memory-register architecture can do a load-and-add in one instruction but RISC prefers separate load and add instructions that take the same time. In this view AES instructions are justified as RISC because implementing an AES round with multiple simple instructions is much slower (6x in Intel's case).

duaneb 14y ago
> One definition of RISC is that every instruction should take one cycle and thus any instruction that takes longer is CISC. This led to MIPS not having multiply, for example. Err, if that was ever really a "RISC" thing, it got dropped quickly. I'm not even sure it's possible to create a sane architecture that runs one cycle per instruction: you need two clock edges just to load and store data from registers, let alone operating on the data. However, optimizing the pipeline so instructions are effectively one cycle makes sense; only one memory cycle per instruction makes sense. Making AES and SHA instructions doesn't really cohere to any definition of RISC I've ever seen: mostly, use as few instructions as possible because you don't have many opcodes to work with in fixed-size instructions. However, I'm also not opposed to these instructions through some dogmatic belief: I think encryption is important enough these days to be optimized to the greatest possible extent without sacrificing general purpose functionality.
- brigade 14y ago
  The RISC vs CISC debate has been dead for years. Doubly so ever since we found the limits of scaling clock frequencies ever higher. After all, the RISC movement started as a reaction to the difficulties of scaling the architectures of the day to faster clock frequencies. Now (decades, really) CPU designers are concentrating on doing more work per clock cycle, which is rather anti-RISC. So the only questions that matter are "can we implement this feature efficiently?" and "does this feature provide enough performance or power gain for the implementation cost?"

duaneb 14y ago

You just described a CISC op.