4 ms·

One CISC is not the same as the other CISC. > You might want to look up the ARM instructions "FJCVTZS" and "AESE", and "SHA256H". The AESE isntruction is a pe

by TomVDB 8y ago

One CISC is not the same as the other CISC. > You might want to look up the ARM instructions "FJCVTZS" and "AESE", and "SHA256H". The AESE isntruction is a perfect example of that. The AESE instruction is a complex instruction that does not execute in the RISC pipeline, but it doesn't add major complexity to the decoder. That makes it very similar to the multiply and divide instructions on the original MIPS CPU: those operated outside of the canonical pipeline as well, with results stored in the HI and LO registers instead of the general purpose register file. Yet I don't think anyone will argue that the 1985 MIPS was not RISC. ;-)

dragontamer 8y ago
> but it doesn't add major complexity to the decoder AESE + AESMC is seen as a singular 8-byte instruction from the decoder. The two instructions are decoded as one operation to maximize the throughput of AES. Yeah, web browsers + web server workloads demand an incredibly fast AES, to the point that ARM is willing to complicate the decoder just to make this one operation faster. > Yet I don't think anyone will argue that the 1985 MIPS was not RISC. ;-) 1985 MIPS wasn't macro-op fusing together instructions for performance gains. The AESE + AESMC instruction pair is straight-up a CISC design (borrowed from Intel's cmp + jnz fusion), complicating the decoder severely but adding huge performance increases in practice. > That makes it very similar to the multiply and divide instructions on the original MIPS CPU: those operated outside of the canonical pipeline as well, with results stored in the HI and LO registers instead of the general purpose register file. AESE and AESMC operate on NEON registers. They coincide with the NEON Pipeline and NEON Registers. They're not "outside" the core by any stretch of the imagination. Maybe you're surprised that ARM has a HUGE series of 128-bit vector instructions. But yeah... ARM's instruction set is very complicated these days. Its basically a CISC processor. https://community.arm.com/android-community/b/android/posts/arm-neon-programming-quick-reference https://community.arm.com/android-community/b/android/posts/... At least, the above is true on A75: https://static.docs.arm.com/101398/0200/arm_cortex_a75_software_optimization_guide_v2.pdf https://static.docs.arm.com/101398/0200/arm_cortex_a75_softw... As you can see in the diagram, the FP0 and FP1 pipelines are all that exist in A75. The AESE / AESMC instruction pair is decoded as one instruction. Its execution is in the FP0 pipeline, just like any other NEON instruction. These are all very CISC-like design decisions. --------------- Anyway, I would argue that ARM stopped being "RISC" as soon as it implemented the "Branch to Java" Jazelle instruction: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489i/CIHBJIIB.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... ARM was always a "pragmatic" architecture. It did what it had to to achieve high performance. Be it a RISC-design choice or a CISC-design choice.
- TomVDB 8y ago
  > AESE + AESMC is seen as a singular 8-byte instruction from the decoder. The two instructions are decoded as one operation to maximize the throughput of AES. Yeah, web browsers + web server workloads demand an incredibly fast AES, to the point that ARM is willing to complicate the decoder just to make this one operation faster. But that's an implementation decision and not inherent to the ISA itself: AESE and AESMC can be implemented as individual instructions without fusing them. The fact that RISC-V advocates fusing certain pure RISC opcode patterns for improved performance doesn't make it any more CISC either. > AESE and AESMC operate on NEON registers. They coincide with the NEON Pipeline and NEON Registers. They're not "outside" the core by any stretch of the imagination. The key part here is "NEON Pipeline and NEON Register". If you can make the split between the traditional pipeline and the additional pipelines, the complexity penalty is contained. The issue with x86 CISCness has always been with having to deal with byte-aligned variable width instructions.
  - dragontamer 8y ago
    > But that's an implementation decision and not inherent to the ISA itself: AESE and AESMC can be implemented as individual instructions without fusing them. On the contrary: the compiler and programmers have performance expectations. Just as modern compilers/programmers expect macro-op fusion between x86 cmp/jmp pairs, modern ARM compilers/programmers expect fusion between AESE and AESMC. Especially when we're talking about articles like "ARM processors like A12X are nearing performan parity...", we have to understand the architectural decisions ARM has made to get to this point. Some CISC-techniques are really, really good for performance. As such, ARM takes those CISC techniques. AESE + AESMC is an excellent example. --------- You can't write a compiler optimizer unless you have an idea of what the CPU core is actually doing. The expectation for any cell-phone ARM chip is to have fusion between AESE and AESMC. That's just how it works these days. Modern compilers are going to work very hard to put AESE + AESMC instructions next to each other to maximize the potential for fusion. > The key part here is "NEON Pipeline and NEON Register". If you can make the split between the traditional pipeline and the additional pipelines, the complexity penalty is contained. Ehhh? AMD Zen has a FP Pipeline and FP Register pools to implement x86. Basically the 64-bit pipeline+registers for normal instructions, and then 128-bit pipeline+registers for SSE / AVX / etc. etc. Does that make AMD Zen's implementation of AMD64 a RISC machine? > The issue with x86 CISCness has always been with having to deal with byte-aligned variable width instructions. ARM kind of has this instruction set called "Thumb2" you probably should get familiar with. Which by the way, all ARM8 chips still support if you put them into AArch32 bit mode. So yeah, all modern ARM chips have a variable-length decoder implemented. Its part of their design. It turns out that variable-length decoder is really, really good for code density. You can compress more data to fit into the limited L1 cache when its variable length. ---------- EDIT: Its really, really difficult for me to consider ARM a real RISC machine. I'm sorry. It supports all of the PDP-11 addressing modes for goodness sake. (post-decrement, pre-increment, etc. etc.). Or is "LDR R0, [R1, r2, LSL #2]" really a RISC-style instruction? RISC vs CISC debate is dead, and has been for decades. ARM just takes good designs, just as all the other CPU designers do. If its a good design, it goes into the chip. ARM even copies the CISC-style "shadow registers" approach to data-dependencies. Intel Skylake has over 200-"shadow registers" internally that it assigns to RAX / RBX / etc. etc., and ARM cores do the same. The ACTUAL hardware registers no longer match the ISA on modern ARM designs.

by TomVDB 8y ago

dragontamer 8y ago

> but it doesn't add major complexity to the decoder AESE + AESMC is seen as a singular 8-byte instruction from the decoder. The two instructions are decoded as one operation to maximize the throughput of AES. Yeah, web browsers + web server workloads demand an incredibly fast AES, to the point that ARM is willing to complicate the decoder just to make this one operation faster. > Yet I don't think anyone will argue that the 1985 MIPS was not RISC. ;-) 1985 MIPS wasn't macro-op fusing together instructions for performance gains. The AESE + AESMC instruction pair is straight-up a CISC design (borrowed from Intel's cmp + jnz fusion), complicating the decoder severely but adding huge performance increases in practice. > That makes it very similar to the multiply and divide instructions on the original MIPS CPU: those operated outside of the canonical pipeline as well, with results stored in the HI and LO registers instead of the general purpose register file. AESE and AESMC operate on NEON registers. They coincide with the NEON Pipeline and NEON Registers. They're not "outside" the core by any stretch of the imagination. Maybe you're surprised that ARM has a HUGE series of 128-bit vector instructions. But yeah... ARM's instruction set is very complicated these days. Its basically a CISC processor. https://community.arm.com/android-community/b/android/posts/arm-neon-programming-quick-reference https://community.arm.com/android-community/b/android/posts/... At least, the above is true on A75: https://static.docs.arm.com/101398/0200/arm_cortex_a75_software_optimization_guide_v2.pdf https://static.docs.arm.com/101398/0200/arm_cortex_a75_softw... As you can see in the diagram, the FP0 and FP1 pipelines are all that exist in A75. The AESE / AESMC instruction pair is decoded as one instruction. Its execution is in the FP0 pipeline, just like any other NEON instruction. These are all very CISC-like design decisions. --------------- Anyway, I would argue that ARM stopped being "RISC" as soon as it implemented the "Branch to Java" Jazelle instruction: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489i/CIHBJIIB.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... ARM was always a "pragmatic" architecture. It did what it had to to achieve high performance. Be it a RISC-design choice or a CISC-design choice.

TomVDB 8y ago
> AESE + AESMC is seen as a singular 8-byte instruction from the decoder. The two instructions are decoded as one operation to maximize the throughput of AES. Yeah, web browsers + web server workloads demand an incredibly fast AES, to the point that ARM is willing to complicate the decoder just to make this one operation faster. But that's an implementation decision and not inherent to the ISA itself: AESE and AESMC can be implemented as individual instructions without fusing them. The fact that RISC-V advocates fusing certain pure RISC opcode patterns for improved performance doesn't make it any more CISC either. > AESE and AESMC operate on NEON registers. They coincide with the NEON Pipeline and NEON Registers. They're not "outside" the core by any stretch of the imagination. The key part here is "NEON Pipeline and NEON Register". If you can make the split between the traditional pipeline and the additional pipelines, the complexity penalty is contained. The issue with x86 CISCness has always been with having to deal with byte-aligned variable width instructions.
- dragontamer 8y ago
  > But that's an implementation decision and not inherent to the ISA itself: AESE and AESMC can be implemented as individual instructions without fusing them. On the contrary: the compiler and programmers have performance expectations. Just as modern compilers/programmers expect macro-op fusion between x86 cmp/jmp pairs, modern ARM compilers/programmers expect fusion between AESE and AESMC. Especially when we're talking about articles like "ARM processors like A12X are nearing performan parity...", we have to understand the architectural decisions ARM has made to get to this point. Some CISC-techniques are really, really good for performance. As such, ARM takes those CISC techniques. AESE + AESMC is an excellent example. --------- You can't write a compiler optimizer unless you have an idea of what the CPU core is actually doing. The expectation for any cell-phone ARM chip is to have fusion between AESE and AESMC. That's just how it works these days. Modern compilers are going to work very hard to put AESE + AESMC instructions next to each other to maximize the potential for fusion. > The key part here is "NEON Pipeline and NEON Register". If you can make the split between the traditional pipeline and the additional pipelines, the complexity penalty is contained. Ehhh? AMD Zen has a FP Pipeline and FP Register pools to implement x86. Basically the 64-bit pipeline+registers for normal instructions, and then 128-bit pipeline+registers for SSE / AVX / etc. etc. Does that make AMD Zen's implementation of AMD64 a RISC machine? > The issue with x86 CISCness has always been with having to deal with byte-aligned variable width instructions. ARM kind of has this instruction set called "Thumb2" you probably should get familiar with. Which by the way, all ARM8 chips still support if you put them into AArch32 bit mode. So yeah, all modern ARM chips have a variable-length decoder implemented. Its part of their design. It turns out that variable-length decoder is really, really good for code density. You can compress more data to fit into the limited L1 cache when its variable length. ---------- EDIT: Its really, really difficult for me to consider ARM a real RISC machine. I'm sorry. It supports all of the PDP-11 addressing modes for goodness sake. (post-decrement, pre-increment, etc. etc.). Or is "LDR R0, [R1, r2, LSL #2]" really a RISC-style instruction? RISC vs CISC debate is dead, and has been for decades. ARM just takes good designs, just as all the other CPU designers do. If its a good design, it goes into the chip. ARM even copies the CISC-style "shadow registers" approach to data-dependencies. Intel Skylake has over 200-"shadow registers" internally that it assigns to RAX / RBX / etc. etc., and ARM cores do the same. The ACTUAL hardware registers no longer match the ISA on modern ARM designs.