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

101–110 of 110 posts

Re: The RISC Deprogrammer

#101

Post by rbanffy »

brucehoult wrote: post #91
rbanffy wrote: post #60

Earlier quoted context omitted.

I kind of agree there is no hard definition because what's "complex" and "reduced" are subjective things. The venerable 6502 was called "RISC before it was cool" and I have to agree its minimalistic ISA made it incredibly capable (and fast, clock for clock) compared to its more ambitious contemporaries such as the Intel 8080/8085, the Motorola 6809, and its arch-nemesis, the Z-80.

The 6502 is nothing like what we would call RISC today (the 6800 is much more modern RISC-like), but the evolution from 6800 to 6502, by largely the same design team at a new company, does somehow follow the RISC "quantitative approach" of getting the most performance from a given number of transistors (the 6800 and 6502 are about the same size), but it does it by adding complexity rather than by simplifying.

> but it does it by adding complexity rather than by simplifying.

That's true - it simplifies a lot of other things alongside the ISA, but it's also apparent that, while it can do a lot of tasks faster than, say, a Z-80, the ISA forces one to take some creative approaches.

Literal ports of Z-80 code to the 6502 usually sucked.

Re: The RISC Deprogrammer

#102

Post by kens »

pencilguin wrote: post #94
kens wrote: post #83

Earlier quoted context omitted.

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…

Veering radically off topic, Ken, I recently became aware of the US Navy's transistorized fleet-wide fire-control computers of the early 1960s. Is there anybody restoring those and presenting museum exhibits of their capabilities? They were fielded as replicated networked real-time load-sharing multi-processors in 1965! Why didn't the Apollo program draw on that experience? Also, speaking of Apollo, Hal Laning made t…

Are you talking about the Navy Tactical Data System (NTDS)? This important system (that Cray worked on) is mostly forgotten, but the book "When Computers Went to Sea" provides good coverage. There's one on exhibit at the Computer History Museum. Apollo did make heavy use of them: the Univac 642B computers from NTDS were used at the ground stations around the world, relaying data to Mission Control.

Re: The RISC Deprogrammer

#103

Post by zozbot234 »

noobermin wrote: post #22
klelatti wrote: post #4

The author seems to have been quite wound up by claims that "my high end desktop / server (insert ARM / RISC-V to taste) is better than your x86 because 'RISC'". Fair enough. It's an 80's debate really. ISA is probably by a long margin not the most important factor in these comparisons. But he says it makes no difference at all without evidence. And he ignores that there is a whole world of simpler (especially in-ord…

In the case it was missed, he actually does talk about that towards the end, that it matters for low powered microcontrollers and for people unwilling to pay for an ARM license, but for the higher powered machines (ARM machines, x86_64 etc), they are both OoO and that is more of what makes them powerful for modern computing ("real" computing by his definition) than does the RISC vs VAX lineage matters.

ISA is a very real constraint on the width of insn decode for something like x86-64, when compared to AArch64 and even more clearly, to RV64C (which competes in code density with x86-64).

Re: The RISC Deprogrammer

#104

Post by pencilguin »

segfaultbuserr wrote: post #99
pencilguin wrote: post #95

Earlier quoted context omitted.

PDP-11 long ints were mixed- endian: high 16 bits, then low 16 bits. But within each half, the low 8 bits, then upper 8 bits. I was sometimes called the "NUXI" format, for how it scrambled the bytes in "UNIX".

What I was saying is that the basic PDP-11 as original designed, is a pure 16-bit machine with no 32-bit capabilities. The Unix C and other compilers used the middle-endian format for 32-bit integers largely as an artificial choice to be compatible with its FPU, as middle-endian was FPU's native long integer format. But the FPU was only a later hardware extension, and was not an inherent part of the basic system, and…

Yes.

Re: The RISC Deprogrammer

#105

Post by pencilguin »

kens wrote: post #102
pencilguin wrote: post #94

Earlier quoted context omitted.

Veering radically off topic, Ken, I recently became aware of the US Navy's transistorized fleet-wide fire-control computers of the early 1960s. Is there anybody restoring those and presenting museum exhibits of their capabilities? They were fielded as replicated networked real-time load-sharing multi-processors in 1965! Why didn't the Apollo program draw on that experience? Also, speaking of Apollo, Hal Laning made t…

Are you talking about the Navy Tactical Data System (NTDS)? This important system (that Cray worked on) is mostly forgotten, but the book "When Computers Went to Sea" provides good coverage. There's one on exhibit at the Computer History Museum. Apollo did make heavy use of them: the Univac 642B computers from NTDS were used at the ground stations around the world, relaying data to Mission Control.

Wow, thanks! Had no idea of their role in Apollo.

Re: The RISC Deprogrammer

#106

Post by sponaugle »

kragen wrote: post #75
sponaugle wrote: post #69

Earlier quoted context omitted.

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 di…

That's great! Presumably you mean 74HC or 74HCT or at least 74ALS, not really 74? How much trouble did you get with noise as you pushed it to 10 MHz with SSI chips? How many CPLDs did you end up using? Thank you for comprehensively rebutting "To be fair, likely none of the readers here have designed a single CPU either :)"

Correct! 74HCs for everything, which are both easy to get and forgiving to use. The first build has 4 PCBs ( ALU, Register file, instruction logic, and memory/LEDs/switches). Each PCB is 12-16 74HCx ICs.

I then did a second design of the same thing using Atmel 1504/1508 CPLDs, and that compressed the design to 2 PCBs - One for the CPU itself and a second for system ram, switches, LEDs, etc. That first board had 5 1504s and 1 1508, although it could have been done in a tad less if I used another 1508. The biggest consumer was the register file since it was 16x 8-bit register, which consumes 128 flip flops.

Re: The RISC Deprogrammer

#107

Post by kragen »

sponaugle wrote: post #106
kragen wrote: post #75

Earlier quoted context omitted.

That's great! Presumably you mean 74HC or 74HCT or at least 74ALS, not really 74? How much trouble did you get with noise as you pushed it to 10 MHz with SSI chips? How many CPLDs did you end up using? Thank you for comprehensively rebutting "To be fair, likely none of the readers here have designed a single CPU either :)"

Correct! 74HCs for everything, which are both easy to get and forgiving to use. The first build has 4 PCBs ( ALU, Register file, instruction logic, and memory/LEDs/switches). Each PCB is 12-16 74HCx ICs. I then did a second design of the same thing using Atmel 1504/1508 CPLDs, and that compressed the design to 2 PCBs - One for the CPU itself and a second for system ram, switches, LEDs, etc. That first board had 5 150…

That sounds great! Have you written it up anywhere publicly? It sounds better designed (e.g., using less chips) than most of the SSI-board CPUs I've seen.

I've been thinking it would be fun to see if I could get JLCPCB to build me such a CPU out of SSI with their PCB assembly service. In theory this is nice and simple: I design the processor at the chip/netlist level, debug the thing in a discrete-event or synchronous simulation with Logisim or something, import it into KiCAD, produce some board layouts, send it to them along with US$50 or so, get back a stack of fully populated SMD PCBs, plug them together, plug it in, start single-stepping the clock while watching what's going on, and then ramp the clock up to see how fast it can run reliably. What surprises am I likely to run into?

Unfortunately I don't think Potato Chips' product line covers things like 1GHz 8-bit registers, but if so that would be pretty entertaining.

Re: The RISC Deprogrammer

#108

Post by kragen »

segfaultbuserr wrote: post #100
pencilguin wrote: post #94

Earlier quoted context omitted.

Veering radically off topic, Ken, I recently became aware of the US Navy's transistorized fleet-wide fire-control computers of the early 1960s. Is there anybody restoring those and presenting museum exhibits of their capabilities? They were fielded as replicated networked real-time load-sharing multi-processors in 1965! Why didn't the Apollo program draw on that experience? Also, speaking of Apollo, Hal Laning made t…

> They were fielded as replicated networked real-time load-sharing multi-processors in 1965! Why didn't the Apollo program draw on that experience? [...] Why do we ignore the real pioneers? I think early computer history in general worked this way. Communication was slow before the Internet. Computer engineering largely existed as an art to build isolated one-off systems. Basic concepts were painstaking reinvented an…

Since Unix was written as an effort to recapture the good parts of Multics after Bell Labs pulled out, and the people working on Unix for the first several years had also been working on Multics before that, I don't think Multics is a good example of "Basic concepts were painstaking reinvented and re-engineered all the time under different circumstances. … die in isolation and obscurity, whose architectures left no influence." The people who worked on Unix for its first decade were intimately familiar with Multics, and Multics was well-documented publicly at the time, unlike certain other systems from the 01960s. The research literature in subsequent years frequently compared and contrasted systems designs with Multics's design.

Even some of the Multics features that weren't in Unix in its first decade, like ACLs, memory-mapped files, process accounting, shared libraries, and SMP support, got added to Unix later.

All this is to say that, to the extent that later systems rejected Multics's design decisions, they did it consciously, not out of ignorance. It's easy to look back at the things Multics attempted, like strong security, and believe that it achieved them, and consequently that more recent systems designs represent backsliding. In many cases, though (like that one!) it did not, and later systems designs solve unanticipated problems that arose from the Multics design choices.

A lot of DSP, speech codec, and even TCP/IP work in later decades was guided by NSA people who were familiar with the SIGSALY history, even if they didn't tell the uncleared people they were working with. See https://ee.stanford.edu/~gray/lpcip/ for a detailed history of speech protocols. In other cases, like the DES, the NSA people deliberately sabotaged the resulting work.

I do agree that preserving historical materials is important.

Re: The RISC Deprogrammer

#110

Post by ruslan »

kragen wrote: post #90
ruslan wrote: post #86

Earlier quoted context omitted.

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?

Well, at least I learnt that pipelining is for good, it speed-ups execution quite a lot. :)
Post reply on HN