Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The RISC Deprogrammer

blog.erratasec.com

Post reply on HN
Print view View original

81–90 of 110 posts

Re: The RISC Deprogrammer

#81

Post by kragen »

kens wrote: post #73
ithkuil wrote: post #19

> Back in the 1980s, most of the major CPUs in the world were big-endian, while Intel bucked the trend being little-endian. The reason is that some engineer made a simple optimization back when the 8008 processor... The article started talking about the VAX and how it was the gold standard everybody competed against. The VAX is little endian. Little endian is not a hack. It's a natural way to represent numbers. Its j…

The history of why the 8008 was little-endian is interesting and predates the 8008. In 1970, the mostly forgotten company CTC released the Datapoint 2200, a desktop computer built from TTL chips (not a microprocessor) and sold as a programmable terminal. It had a serial processor using shift-register memory chips. It was an 8-bit processor but since it operated on one bit at a time, it had to start with the lowest bi…

Hmm, a minor quibble: "VLSI" would be normally more than 10k gates or 100k transistors on a single chip, wouldn't it? But the 8008 had only about 3500 transistors (I don't see an exact count in http://www.righto.com/2016/12/die-photos-and-analysis-of_24....) and so probably about 1000–1500 gates, so I think it should be called "LSI" rather than "VLSI".

A funny thing about the 8008 is that Intel's manual for its instruction set is unnecessarily shitty — even if you didn't know the history with Datapoint, the Intel manual is obviously not by the people who designed the instruction set because it's in hexadecimal, a tradition sadly followed by the 8080 and 8086 manuals. The Datapoint manuals, by contrast, are all in octal, making the machine code enormously easier to understand. (The H8 I grew up with used an Intel chip, but the front panel monitor program used octal.)

Re: The RISC Deprogrammer

#82

Post by kragen »

baryphonic wrote: post #59
noobermin wrote: post #10

So, this is interesting so far and I'm bookmarking it for the depth of the author's historical knowledge, but saying "horizontal microcode" was the main difference that "no one talks about"...I mean I was told this was the very difference that make RISC distinct from x86 and friends (what I see now were VAX-like archs), the simpler transistor logic without the crazy micro-programs and the pipelining, I thought this w…

You're absolutely right. I was waiting to see what the big misunderstanding was about RISC, and I actually rolled my eyes when I saw _horizontal microcode_ bolded. It's an implementation detail.

You seem to have read noobermin as saying the opposite of what I read them as saying, because to my eyes the conversation looks like this:

     X is Y
     You're absolutely right.  X is totally not Y

Re: The RISC Deprogrammer

#83

Post by kens »

kragen wrote: post #81
kens wrote: post #73

Earlier quoted context omitted.

The history of why the 8008 was little-endian is interesting and predates the 8008. In 1970, the mostly forgotten company CTC released the Datapoint 2200, a desktop computer built from TTL chips (not a microprocessor) and sold as a programmable terminal. It had a serial processor using shift-register memory chips. It was an 8-bit processor but since it operated on one bit at a time, it had to start with the lowest bi…

Hmm, a minor quibble: "VLSI" would be normally more than 10k gates or 100k transistors on a single chip, wouldn't it? But the 8008 had only about 3500 transistors (I don't see an exact count in http://www.righto.com/2016/12/die-photos-and-analysis-of_24.... ) and so probably about 1000–1500 gates, so I think it should be called "LSI" rather than "VLSI". A funny thing about the 8008 is that Intel's manual for its inst…

Yes, it's kind of amazing how the 8080/Z80/8086 instructions sets make much more sense in octal, but are always displayed in hexadecimal. In hex, you can kind of see some patterns, but everything is obvious in octal. The 6502 is also based on bit triples, but they grouped the bits from the top, so octal doesn't make things any better.

The Datapoint 2200, by the way, used decimal decoder chips to decode the octal parts of the instruction set and simply ignored the 8 and 9 outputs.

Re: The RISC Deprogrammer

#84

Post by brucehoult »

KingOfCoders wrote: post #47
flohofwoe wrote: post #38

Earlier quoted context omitted.

> Yes, "8-bit" refers to the ALU. By that definition, the Z80 would be a 4-bit CPU ;) https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-... ...but if you take the data bus width, then the 8088 would be an 8-bit CPU, which isn't quite right either... But you also can't take the address bus width, because modern "64-bit" CPUs can't actually address 64 bits of physical memory... I think it's best to treat the…

You're right. Having written quite some Z80 code and 68k code, I need to think about this. This is decades in the past, I think outside of demo code I often used move.l in 68k so it would be a 32bit CPU to me, but seldom used double registers on the Z80 so it feels like an 8bit CPU. Perhaps that was one of the reasons the jump from the Z80 to the 68k felt so huge (perhaps it was the number and flexibility of register…

There's not much to think about. Bitness refers to the ISA, not the implementation. It's about what registers there are and what operations on them. It is what the programmer can write.

All CPUs that execute the same programs (in their native mode) are the same bitness. This is fundamental.

If a 68040 is 32 bit then so are the 68000 and 68008.

Most of the so-called "8 bit" CPUs weren't really. They were mixed 8/16 bit. Especially something like the z80 which had a lot of 16 bit registers, could do 16 bit adds and loads and stores. But not 16 bit compares or moves in the registers (needed two 8 bit moves). But even the 6800 and 6502 had certain 16 bit operations to support the 16 bit address space. The 6809 was even more 16 bit in being able to do 16 bit moves and subtracts and compares -- other than the lack of segment registers it was very very similar to the 16 bit 8088.

One problem with the terminology is that those early microprocessor instruction sets weren't Instruction Set Architectures. There was only ever one implementation of them, so people (including their manufacturers) tended to conflate implementation details and instruction set details.

Re: The RISC Deprogrammer

#85

Post by nuc1e0n »

thethirdone wrote: post #78
nuc1e0n wrote: post #76

So my takeaway from this article is this: RISC largely displaced CISC except in legacy situations as you could get better throughput for the same number of transistors by moving work into the compiler. In turn Out-of-Order execution largely displaced RISC as you could get better throughput for the same number of transistors by moving more work into the compiler. How else might processor topology design dogma be hinde…

> In turn Out-of-Order execution largely displaced RISC as you could get better throughput for the same number of transistors by moving more work into the compiler. What work does OoO execution displace to the compiler? I thought that OoO CPUs get better performance on the exact same programs compared to in order CPUs.

Ensuring register accesses are interleaved in a good way right?

Re: The RISC Deprogrammer

#86

Post by ruslan »

noobermin wrote: post #24
kragen wrote: post #21

Earlier quoted context omitted.

I don't think Rob has ever designed a single CPU, much less measured the effects of different tradeoffs.

To be fair, likely none of the readers here have designed a single CPU either :)

I toyed with my own implementation of one-stage RV32I for FPGAs, does this count ? ;)

Re: The RISC Deprogrammer

#87

Post by kragen »

kens wrote: post #83
kragen wrote: post #81

Earlier quoted context omitted.

Hmm, a minor quibble: "VLSI" would be normally more than 10k gates or 100k transistors on a single chip, wouldn't it? But the 8008 had only about 3500 transistors (I don't see an exact count in http://www.righto.com/2016/12/die-photos-and-analysis-of_24.... ) and so probably about 1000–1500 gates, so I think it should be called "LSI" rather than "VLSI". A funny thing about the 8008 is that Intel's manual for its inst…

Yes, it's kind of amazing how the 8080/Z80/8086 instructions sets make much more sense in octal, but are always displayed in hexadecimal. In hex, you can kind of see some patterns, but everything is obvious in octal. The 6502 is also based on bit triples, but they grouped the bits from the top, so octal doesn't make things any better. The Datapoint 2200, by the way, used decimal decoder chips to decode the octal part…

Shit, that's brilliant! I guess the 74138 didn't exist yet? JiaLiChuang PCB has the 74HC138 in their "basic" parts list for free PCB pick-and-place but no decimal decoders. The CD405[123] did exist but were presumably far too slow for Datapoint.

Re: The RISC Deprogrammer

#89

Post by thethirdone »

nuc1e0n wrote: post #85
thethirdone wrote: post #78

Earlier quoted context omitted.

> In turn Out-of-Order execution largely displaced RISC as you could get better throughput for the same number of transistors by moving more work into the compiler. What work does OoO execution displace to the compiler? I thought that OoO CPUs get better performance on the exact same programs compared to in order CPUs.

Ensuring register accesses are interleaved in a good way right?

Register renaming allows CPUs to eliminate stalls due to reuse of a register; I have not noticed any compiler putting particular emphasis on interleaving accesses well.

That is actually more of a problem on in order CPUs because a single stall will hold up the entire CPU instead of take longer to commit while other stuff is going on.

Re: The RISC Deprogrammer

#90

Post by kragen »

ruslan wrote: post #86
noobermin wrote: post #24

Earlier quoted context omitted.

To be fair, likely none of the readers here have designed a single CPU either :)

I toyed with my own implementation of one-stage RV32I for FPGAs, does this count ? ;)

I think that's a lot more than Rob has done. What did you learn?
Post reply on HN