5 ms·

>remember that the initial RISC proposal was in contrast to the PDP instruction set, which was kind of ridiculously over specialized for the technology of the t

by simias 7y ago

>remember that the initial RISC proposal was in contrast to the PDP instruction set, which was kind of ridiculously over specialized for the technology of the time. That's a good point and I expect that it still somewhat holds true today: many of the RISC supporters (and I'm one of them) effectively assimilate CISC with x86 since that's by far the most popular CISC instruction set out there these days[1]. And x86 is the C++ of instruction sets: decades and decades of legacy feature which shouldn't be used in modern code, a large selection of paradigms copied from whatever other instruction set was popular at the time. You want to do BCD? We have opcodes for that (admittedly no longer supported in long mode, but it's there). Also do you like prefixes? Asking for a friend. But obviously that's a bit of a fallacy, one could design a modern CISC-y IA without all the legacy baggage of x86. It's not so much that I love MIPS or RISC V, it's that I don't want to have to deal with x86 anymore. [1] We don't yet consider ARM CISC, right?

Taniwha 7y ago
Actually it was in contrast to the Vax instruction set ... the PDP instruction set is something else (and some Vax's had a PDP emulation mode ....)
- monocasa 7y ago
  VAX was a crazy town ISA too, with stuff like single isntruction polynomial evaluation.
  - dragontamer 7y ago
    Crazy for its age, but all modern processors (x86, ARM, and Power9) implement a polynomial multiplication. ARM: vmull.p8 Intel: PCLMULQDQ Power9: I forget, but trust me, its in there somewhere. IIRC, they're all 64-bit carryless (or polynomial) multiplications. The funniest part is that ARM and Power9 still claim to be "reduced instruction set computers", despite having highly specialized instructions like these. Power9 is the funniest: implementing hardware-level decimal-floats (for those bankers running COBOL), quad-floats (for the scientific community), Polynomial-Multiplication and more.
    - floatboth 7y ago
      Well, the meaning of "reduced" has shifted from "not having specialized instructions" to "load-store and preferably fixed-length". Here's a CRC32 impl using POWER8/9 polynomial instructions: https://github.com/antonblanchard/crc32-vpmsum https://github.com/antonblanchard/crc32-vpmsum — coincidentally, you don't have to do this on ARM, ARM just has CRC32 instructions. > hardware-level decimal-floats (for those bankers running COBOL) IBM being IBM :) I've heard somewhere that they are sharing some internals between POWER and z/Architecture (mainframe) chips. No idea how true it is and how much is shared if true, but a scenario like "decimal floats were implemented because mainframes are using the same backend with a different frontend, so we exposed them in the POWER frontend too" sounds quite plausible.
      - monocasa 7y ago
        IBM likes decimal floats because of COBOL (and maybe RPG?). To be fair, even back in the day decimal arthimetic could at least have an argument made for it on RISC chips. https://yarchive.net/comp/bcd_instructions.html https://yarchive.net/comp/bcd_instructions.html
      - CalChris 7y ago
        Well, the meaning of "reduced" has shifted from "not having specialized instructions" to "load-store and preferably fixed-length". Ain't that the truth. Reduced never meant anything; they never defined it. Patterson said they cooked up the name on the way to a grant presentation. I think they should call it Warmed Over Cray. What was new in RISC that wasn't in Cray? It was like the Geometry Engine; it was possible for an academic department to accomplish but that doesn't mean they accomplished anything that hadn't already been done. preferably fixed-length Or fixed-length/2.
    - monocasa 7y ago
      Not GF polynomial multiplication, full Horner's method polynomial eval in a single instruction. https://web.archive.org/web/20181126134850/http://uranium.vaxpower.org/~isildur/vax/week.html https://web.archive.org/web/20181126134850/http://uranium.va...
  - Taniwha 7y ago
    Which resulted in a particular problem .... worst case an instruction could cause 21 different page faults (because of all the operands), that meant that every process had to be able to have an in-core working set of a minimum of 21 (512-byte) pages in order to make progress, at a time when memory was not cheap and plentiful
    - Taniwha 7y ago
      more importantly too many operands with side effects (auto increments) result in complexity in the handling of exceptions (do you restart or save partial internal state - compare the 68020 with the 68040 for example)
      - monocasa 7y ago
        Yep. I'm playing with a 68k decoder frontend for a modified boom core. Indirect memory accesses are the bane of my existence at the moment.
        Taniwha 7y ago
        - 68000s were just broken (couldn't restart a page fault) - we still put unix on it, hacked the compiler to probe the stack to do stack extension on swapping only systems - 68010s were essentially a 68000 with this fixed - unix could do a real paging system - 68020s dumped their entire microcode state on the kernel stack - to do signals correctly (ie recusively) unix systems had to be able to spill this to user space and validate it on the way back in - 68030s and 68040s were saner and restarted exceptions in useful ways
        anyfoo 7y ago
        Wow. Having pretty much ventured from 6502 directly to the 386 and later ARM, 68k was something I never really took a close look at. Was that limitation in the original 68000 unintentional, or did they just not design for faulting in virtual memory at page granularity? After all, you don't need to be able to restart on a page fault if you just swap in whole tasks out and back into memory just before switching to them (which you know when you're going to do), and you still get virtual memory's benefit of the swapped in tasks being able to occupy different physical, and discontiguous, memory regions without the task itself noticing. So did they only design for that, or did they actually make a mistake?
com2kid 7y ago
The amount of silicon legacy code takes up literally decreases non-linearly with each process shrink. The amount of baggage x86 is carrying around now days long ago shrunk to the point of not mattering. And sure, if some ancient compiler spits out some opcode that Intel long ago stopped optimizing, it may take 10x the clock cycles it used to take back in the days of 386s, it is still going to run 100x faster at the end of the day. > We don't yet consider ARM CISC, right? I think ARM64 was an attempt to prevent that from happening! I haven't looked into it at all so I am not sure how successful they were. But it was starting to get pretty close there for awhile.
floatboth 7y ago
ARM is load-store and fixed-length, which seem to be the defining traits of "RISCiness" these days :) btw, one of the "best" x86 features is the string instructions: https://lobste.rs/s/m7ioti/risc_is_fundamentally_unscalable#c_ijkt8v https://lobste.rs/s/m7ioti/risc_is_fundamentally_unscalable#... > the destination operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location
- ant6n 7y ago
  In thumb2 mode, an ARM will not be fixed-length: instructions may be 16 or 32 bits long.
  - floatboth 7y ago
    I'm talking about aarch64, I don't care about 32-bit stuff.
marcosdumay 7y ago
> one could design a modern CISC-y IA without all the legacy baggage of x86 You are talking about ARM here, aren't you? But seriously, there is no reason not to say ARM is CISC. It's not the old AI it used to be anymore.
CalChris 7y ago
Also do you like prefixes? Asking for a friend. If you like x86 at all then prefixes are not a good thing but indeed a great thing. Prefixes are what allowed AMD to completely destroy Intel's Itanium. They simply took x86 and reused the REX prefix to access 16 more registers. Yeah, the committed a few other architectural atrocities before the god of expediency, but they won and Intel had to crawl back and beg forgiveness in the x86 space that they owned.

by simias 7y ago

Taniwha 7y ago

Actually it was in contrast to the Vax instruction set ... the PDP instruction set is something else (and some Vax's had a PDP emulation mode ....)

monocasa 7y ago
VAX was a crazy town ISA too, with stuff like single isntruction polynomial evaluation.
- dragontamer 7y ago
  Crazy for its age, but all modern processors (x86, ARM, and Power9) implement a polynomial multiplication. ARM: vmull.p8 Intel: PCLMULQDQ Power9: I forget, but trust me, its in there somewhere. IIRC, they're all 64-bit carryless (or polynomial) multiplications. The funniest part is that ARM and Power9 still claim to be "reduced instruction set computers", despite having highly specialized instructions like these. Power9 is the funniest: implementing hardware-level decimal-floats (for those bankers running COBOL), quad-floats (for the scientific community), Polynomial-Multiplication and more.
  - floatboth 7y ago
    Well, the meaning of "reduced" has shifted from "not having specialized instructions" to "load-store and preferably fixed-length". Here's a CRC32 impl using POWER8/9 polynomial instructions: https://github.com/antonblanchard/crc32-vpmsum https://github.com/antonblanchard/crc32-vpmsum — coincidentally, you don't have to do this on ARM, ARM just has CRC32 instructions. > hardware-level decimal-floats (for those bankers running COBOL) IBM being IBM :) I've heard somewhere that they are sharing some internals between POWER and z/Architecture (mainframe) chips. No idea how true it is and how much is shared if true, but a scenario like "decimal floats were implemented because mainframes are using the same backend with a different frontend, so we exposed them in the POWER frontend too" sounds quite plausible.
    - monocasa 7y ago
      IBM likes decimal floats because of COBOL (and maybe RPG?). To be fair, even back in the day decimal arthimetic could at least have an argument made for it on RISC chips. https://yarchive.net/comp/bcd_instructions.html https://yarchive.net/comp/bcd_instructions.html
    - CalChris 7y ago
      Well, the meaning of "reduced" has shifted from "not having specialized instructions" to "load-store and preferably fixed-length". Ain't that the truth. Reduced never meant anything; they never defined it. Patterson said they cooked up the name on the way to a grant presentation. I think they should call it Warmed Over Cray. What was new in RISC that wasn't in Cray? It was like the Geometry Engine; it was possible for an academic department to accomplish but that doesn't mean they accomplished anything that hadn't already been done. preferably fixed-length Or fixed-length/2.
  - monocasa 7y ago
    Not GF polynomial multiplication, full Horner's method polynomial eval in a single instruction. https://web.archive.org/web/20181126134850/http://uranium.vaxpower.org/~isildur/vax/week.html https://web.archive.org/web/20181126134850/http://uranium.va...
- Taniwha 7y ago
  Which resulted in a particular problem .... worst case an instruction could cause 21 different page faults (because of all the operands), that meant that every process had to be able to have an in-core working set of a minimum of 21 (512-byte) pages in order to make progress, at a time when memory was not cheap and plentiful
  - Taniwha 7y ago
    more importantly too many operands with side effects (auto increments) result in complexity in the handling of exceptions (do you restart or save partial internal state - compare the 68020 with the 68040 for example)
    - monocasa 7y ago
      Yep. I'm playing with a 68k decoder frontend for a modified boom core. Indirect memory accesses are the bane of my existence at the moment.
      - Taniwha 7y ago
        - 68000s were just broken (couldn't restart a page fault) - we still put unix on it, hacked the compiler to probe the stack to do stack extension on swapping only systems - 68010s were essentially a 68000 with this fixed - unix could do a real paging system - 68020s dumped their entire microcode state on the kernel stack - to do signals correctly (ie recusively) unix systems had to be able to spill this to user space and validate it on the way back in - 68030s and 68040s were saner and restarted exceptions in useful ways
        anyfoo 7y ago
        Wow. Having pretty much ventured from 6502 directly to the 386 and later ARM, 68k was something I never really took a close look at. Was that limitation in the original 68000 unintentional, or did they just not design for faulting in virtual memory at page granularity? After all, you don't need to be able to restart on a page fault if you just swap in whole tasks out and back into memory just before switching to them (which you know when you're going to do), and you still get virtual memory's benefit of the swapped in tasks being able to occupy different physical, and discontiguous, memory regions without the task itself noticing. So did they only design for that, or did they actually make a mistake?

com2kid 7y ago

The amount of silicon legacy code takes up literally decreases non-linearly with each process shrink. The amount of baggage x86 is carrying around now days long ago shrunk to the point of not mattering. And sure, if some ancient compiler spits out some opcode that Intel long ago stopped optimizing, it may take 10x the clock cycles it used to take back in the days of 386s, it is still going to run 100x faster at the end of the day. > We don't yet consider ARM CISC, right? I think ARM64 was an attempt to prevent that from happening! I haven't looked into it at all so I am not sure how successful they were. But it was starting to get pretty close there for awhile.

floatboth 7y ago

ARM is load-store and fixed-length, which seem to be the defining traits of "RISCiness" these days :) btw, one of the "best" x86 features is the string instructions: https://lobste.rs/s/m7ioti/risc_is_fundamentally_unscalable#c_ijkt8v https://lobste.rs/s/m7ioti/risc_is_fundamentally_unscalable#... > the destination operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location

ant6n 7y ago
In thumb2 mode, an ARM will not be fixed-length: instructions may be 16 or 32 bits long.
- floatboth 7y ago
  I'm talking about aarch64, I don't care about 32-bit stuff.

marcosdumay 7y ago

> one could design a modern CISC-y IA without all the legacy baggage of x86 You are talking about ARM here, aren't you? But seriously, there is no reason not to say ARM is CISC. It's not the old AI it used to be anymore.

CalChris 7y ago

Also do you like prefixes? Asking for a friend. If you like x86 at all then prefixes are not a good thing but indeed a great thing. Prefixes are what allowed AMD to completely destroy Intel's Itanium. They simply took x86 and reused the REX prefix to access 16 more registers. Yeah, the committed a few other architectural atrocities before the god of expediency, but they won and Intel had to crawl back and beg forgiveness in the x86 space that they owned.