I don’t doubt the author knows a lot about this, but the case being made constantly has things that even a cursory reading highlights as nonsense. Like RISC requiring a high-level language compiler and operating system, while the dominant “RISC” chip on the planet originally had an operating system written entirely in assembly. And the technical distinction between “real” and “not real CPUs” quietly ignoring the fact that the 80s and 90s were completely dominated by “not real” computers.
The RISC Deprogrammer
61–70 of 110 posts
Re: The RISC Deprogrammer
#62So x86 chips are only inefficient because they're fast? Or because Intel only makes laptop and desktop chips? So how did they fail sooo badly at breaking into the mobile CPU market? Their Android phones were notoriously slow and inefficient. Also isn't one of the reasons the M1 is so fast because it has so many instruction decoders which is much easier because of the ISA? The author clearly knows a lot of history but…
Especially, just consigning Hennessy and Patterson as a lousy book and ignoring what they said at the time, it makes the blogpost apparent for what it is: an illogical rant. On the one hand, Dave Patterson, Turing Award winner. On the other, Rob Graham, notorious troll. Hmmm…
Re: The RISC Deprogrammer
#63This article is a polemic. Don't take it personally. Enjoy! Also it's clear they are well versed in the topic. You may not agree but it is great food for thought.
Just because Rob Graham is of a certain age doesn’t mean he’s well-versed in the topic.
Re: The RISC Deprogrammer
#64This "debunking" is itself mostly plausible-sounding bunk. It gets a lot of details simply wrong. For example, the 68030 wasn't "around 100000 transistors", it was 273000 [1]. The 80386 was very similar at 275000 [2]. By comparison, the ARM1 was around 25000 transistors[3], and yet delivered comparable or better performance. That's a factor of 10! So RISC wasn't just a slight re-allocation of available resources, it…
>whereas with a variable length instruction stream you need all sorts of interconnects between the decode units, and these interconnects add significant complexity and latency. I find worth noting this is not always the case. e.g. RISC-V C extension provides variable length instructions, but they're still either 16 or 32 bit. Special care has been put into making the decoding overhead of dealing with this situation n…
> e.g. RISC-V C extension provides variable length instructions, but they're still either 16 or 32 bit.
It's more than that. In RISC-V, you only need the first two bits of each instruction to determine whether it's a 16 bit or 32 bit instruction; you don't need to decode an instruction to know its length.
> [...] we see the cache sizes M1/M2 need just to deal with this, [...]
Do the M1/M2 need these cache sizes, or do they have these cache sizes because they can have these cache sizes, due to having a 4x larger page size by default? (Normally, page size wouldn't be that much of a problem for instruction caches, but for x86 it is because the x86 ISAs don't require explicit instruction cache invalidation on self-modifying code; x86 processors would likely have larger L1 instruction cache sizes if they could get away with it.)
Re: The RISC Deprogrammer
#65Earlier quoted context omitted.
>whereas with a variable length instruction stream you need all sorts of interconnects between the decode units, and these interconnects add significant complexity and latency. I find worth noting this is not always the case. e.g. RISC-V C extension provides variable length instructions, but they're still either 16 or 32 bit. Special care has been put into making the decoding overhead of dealing with this situation n…
> e.g. RISC-V C extension provides variable length instructions, but they're still either 16 or 32 bit. It's more than that. In RISC-V, you only need the first two bits of each instruction to determine whether it's a 16 bit or 32 bit instruction; you don't need to decode an instruction to know its length. > [...] we see the cache sizes M1/M2 need just to deal with this, [...] Do the M1/M2 need these cache sizes, or d…
> In RISC-V, you only need the first two bits of each instruction to determine whether it's a 16 bit or 32 bit instruction
Isn't it one bit in the beginning(?) of each 16-bit instruction? So a 32-bit instruction has this information duplicated in the same place in the latter 16-bit half, since a decoder has to be able to decide whether it's trying to decode a 16-bit instruction or whether it's in the middle of a 32-bit instruction.
The above assuming that the common strategy for implementing a parallel decoder for RVC is to start decoding at each 16-bit offset, and then throw away those cases where it turns out that it was in the middle of a 32-bit instruction, and that RVC has been designed with this implementation strategy in mind.
Re: The RISC Deprogrammer
#66Earlier quoted context omitted.
Mostly everyone else seems to define the bitness of CPUs by their capacity to add numbers in one go, not by the address space they can address. What "everyone" calls 8bit computers could address 64kb of address space, not 256 bytes. Everyone can call a table a chair, but it doesn't make communication easier.
> Mostly everyone else seems to define the bitness of CPUs by their capacity to add numbers in one go, not by the address space they can address. Nah, only historically. Yes, "8-bit" refers to the ALU. Back in the day, 16-bit was similar. But even then it was muddy, because when talking about operating systems like Unix or NT the key question about bitness would be in the context of a 32-bit flat addressing model, no…
> By the time the 64-bit era rolled around, the "64-bits" definitely referred to address space.. The original Pentium had a 64-bit data path and had instructions (MMX, eg PADDQ) that could operate on 64-bit numbers - no one would call it 64-bit. By the early 2000s with the big push to mainstreaming 64-bit, it was all breaking out of the 4GB address space limitation - not the width of data.
We're ~20 years down the line and none of these "64-bit" processors support 64-bit addressing yet. Most support up to 48-bits of addressing, with some newer intel chips supporting 57-bit addresses with 5-level paging.
I always took the bit-ness of the processor to refer to the data bus size between the cpu and main memory, aka, the size of a machine word.
Re: The RISC Deprogrammer
#67Earlier quoted context omitted.
> e.g. RISC-V C extension provides variable length instructions, but they're still either 16 or 32 bit. It's more than that. In RISC-V, you only need the first two bits of each instruction to determine whether it's a 16 bit or 32 bit instruction; you don't need to decode an instruction to know its length. > [...] we see the cache sizes M1/M2 need just to deal with this, [...] Do the M1/M2 need these cache sizes, or d…
> In RISC-V, you only need the first two bits of each instruction to determine whether it's a 16 bit or 32 bit instruction Isn't it one bit in the beginning(?) of each 16-bit instruction? So a 32-bit instruction has this information duplicated in the same place in the latter 16-bit half, since a decoder has to be able to decide whether it's trying to decode a 16-bit instruction or whether it's in the middle of a 32-b…
> Isn't it one bit in the beginning(?) of each 16-bit instruction?
No, it's the first two bits of every instruction (RISC-V is little-endian, so these are the least-significant bits). Two bits have four possible values, three of them are for 16-bit instructions, one of them is for 32-bit instructions.
> So a 32-bit instruction has this information duplicated in the same place in the latter 16-bit half, since a decoder has to be able to decide whether it's trying to decode a 16-bit instruction or whether it's in the middle of a 32-bit instruction.
No, that information is not duplicated. The decoder cannot know whether it's in the middle of a 32-bit instruction or not; it has to decode the length of all preceding instructions. That's why it's important that you can know the instruction length without decoding the instruction, so that simple logic can tell decoders other than the first whether they're in the start or in the middle of an instruction.
Re: The RISC Deprogrammer
#6832-bit versions of OS/2 and multiple versions of Unix ran on the 80386 and 80486 long before Windows NT ever ran on most desktops. Client PCs were mostly Windows 95/98/ME until the XP era. Servers and some professional workstations were NT 3.1, 3.51, and 4.0 then Windows 2000. Few business desktops and home computers ran NT/2000 at all.
Re: The RISC Deprogrammer
#69Earlier quoted context omitted.
To be fair, likely none of the readers here have designed a single CPU either :)
It's a standard thing to do in EE curricula; you normally do it in a one-semester class, and there are literally thousands of open-source synthesizable CPU cores on GitHub now. Some one-semester classes go so far as to design ASICs and, if they pass DRCs, get them fabbed through something like MOSIS or CMP. To take three examples to show that designing a CPU is less work than writing a novel: - Chuck Thacker's "A Tin…
Indeed, I suspect most computer engineering students have done some level of CPU design in their coursework. I rather enjoy the design process, and have done many different designs over the years in an attempt to learn about different optimization and design decisions. I typically do something on paper first, then in some simulation, and sometimes into HDL an on an FPGA, or in some cases discrete logic.
I recently did a very simple 16 instruction/16 register RISC-like design (no microcode) built using just 74xx series logic which was successful at over 10MHz, and I then took that design and implemented it in CPLDs to see how it would compress. It really is an enjoyable process and a nice change from the daily software engineering tasks.
Napkin CPU design should be table topic at your next dinner!
Re: The RISC Deprogrammer
#70Earlier quoted context omitted.
> In RISC-V, you only need the first two bits of each instruction to determine whether it's a 16 bit or 32 bit instruction Isn't it one bit in the beginning(?) of each 16-bit instruction? So a 32-bit instruction has this information duplicated in the same place in the latter 16-bit half, since a decoder has to be able to decide whether it's trying to decode a 16-bit instruction or whether it's in the middle of a 32-b…
> Isn't it one bit in the beginning(?) of each 16-bit instruction? No, it's the first two bits of every instruction (RISC-V is little-endian, so these are the least-significant bits). Two bits have four possible values, three of them are for 16-bit instructions, one of them is for 32-bit instructions. > So a 32-bit instruction has this information duplicated in the same place in the latter 16-bit half, since a decode…
Huh, that's surprising. I looked it up and indeed you're correct. Well, oof. Though to be fair I don't now how much of an impediment that is for actually implementing very wide decoders in practice. Hopefully not too bad.