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

91–100 of 110 posts

Re: The RISC Deprogrammer

#91

Post by brucehoult »

rbanffy wrote: post #60
snvzz wrote: post #16

Earlier quoted context omitted.

>It kind of pushed their own definition of what RISC is. That's intentional. A straw man tends to be easier to attack.

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.

Re: The RISC Deprogrammer

#92

Post by ithkuil »

masklinn wrote: post #58
ufo wrote: post #49

Earlier quoted context omitted.

I think it's neat that Arabic, where we got the numbers from, is an RTL language. From their point of view the numbers are little endian.

OTOH Arabic got its numerals from indic systems, and indic scripts are generally LTR, which points to big median being “more natural”. It also matches the spelling of positional numerals in most languages, and does make sense from a convenience point of view: when talking it’s easier to round off by just stopping as you go than to figure out what rounding you should apply beforehand. If you spell out numbers in littl…

Zwei und dreissig ? Wahid wa ishrun?

Yes most modern languages have lost little endiannes and those that kept it use only for the first 100 numbers.

That's because for bigger and bigger numbers you're correctly pointing out that big endian is more useful when saying the numbers aloud since you can often ignore the less significant digits.

My original point was different though:

You can easily render little endian hexdumps equally readable as big endian hexdumps by just writing them in the order that is meant for numbers, namely right to left.

We even align numbers to the right in spreadsheets. That's the same thing.

Look at an old DEC manual (digital Unix, or VMS) and you'll see hexdumps where the numeric part is aligned from center towards the left and the ASCII part is aligned from the center to the right.

With this layout you can easily read multibyte numbers naturally.

Re: The RISC Deprogrammer

#93

Post by pencilguin »

The article is almost completely right, aside from missing that VAX was little-endian.

But if 68k was really a 16-bit design, then Z-80 was a really 4-bit chip, because that was the size of its ALU. What matters, really, is the register size, and how much work you can do in one instruction. Federico Faggin ("fajjeen", btw) recognized that the Z-80 did not need its 8-bit result in the next click cycle anyway, so took two 4-bit cycles, and nobody was the wiser.

Re: The RISC Deprogrammer

#94

Post by pencilguin »

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…

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 the first-ever actual compiler, in the mid-late-'50s, and a real-time multi-tasking load-shedding OS for Apollo, and was snubbed for the Turing Award every year after right up to his death. I never even encountered his name until I read Sunburst and Luminary.

Why do we ignore the real pioneers?

Re: The RISC Deprogrammer

#95

Post by pencilguin »

segfaultbuserr wrote: post #43
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…

VAX's predecessor, the PDP-11, is also a little-endian architecture in its basic form (and the PDP-11 was also a major source of influence to many microprocessor designers, just like VAX's influence on Unix workstations). The "PDP-endian" is only a quirk due to its Floating Point Unit's long integer and double-precision floating point formats. The FPU was an extra module attached to the processor, and the original PD…

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".

Re: The RISC Deprogrammer

#96

Post by pencilguin »

snvzz wrote: post #15

The article (like most RISC hit pieces) neglects the implicit value of simplicity. Complexity needs to be justified, and the article does a very poor job there.

There has not been any detectable simplicity in anything called RISC in decades. Even things that seem simple looked at from outside are fiendishly fiddly when you look closer.

Re: The RISC Deprogrammer

#97

Post by noobermin »

jabl wrote: post #45
noobermin wrote: post #33

Earlier quoted context omitted.

Btw, giving rust like safety is even more fine-grained than this, it would have to ensure ownership for pieces of memory within one program, which seems amazingly tedious to do in hardware.

Well, that's what CHERI does, more or less.

Thanks for the name, after looking it up, it sounds interesting.

Re: The RISC Deprogrammer

#98

Post by nuc1e0n »

thethirdone wrote: post #89
nuc1e0n wrote: post #85

Earlier quoted context omitted.

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.

So if compilers did this better then processors wouldn't need the extra complexity and the transistors needed to support it themselves?

Re: The RISC Deprogrammer

#99

Post by segfaultbuserr »

pencilguin wrote: post #95
segfaultbuserr wrote: post #43

Earlier quoted context omitted.

VAX's predecessor, the PDP-11, is also a little-endian architecture in its basic form (and the PDP-11 was also a major source of influence to many microprocessor designers, just like VAX's influence on Unix workstations). The "PDP-endian" is only a quirk due to its Floating Point Unit's long integer and double-precision floating point formats. The FPU was an extra module attached to the processor, and the original PD…

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 it's not enforced by the basic PDP-11 insturction set. It's entirely possible to modify the UNIX C compiler to store long integers in little endian.

Re: The RISC Deprogrammer

#100

Post by segfaultbuserr »

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…

> 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 and re-engineered all the time under different circumstances. Lack of standard architectures made transfer of concepts difficult. And in the end, many computer designs die in isolation and obscurity, whose architectures left no influence, and no heritage can be found in later computers. The game only changed after minicomputers, which turned computers into mass-market products. Microprocessors did it to a greater degree.

NSA's SIGSALY system, built in late World War 2 that already pioneered digital-to-analog conversion, digital signal processing, digital PCM audio, speech compression codec, and cryptography. But I doubt later DSP engineers ever heard of this project.

Or consider Multics, a relatively late and well-known system. Today it would be called a "cloud-computing" operation system, designed for a world where computers are public utilities to provide time-sharing service to the public, in a way similar to telephone or electricity. Its operating system designed for strong reliability and security. But its architecture was all but forgotten (the hierarchical file system survived in Unix, but it was a minor feature compared to Multics real achievements - and I suspect it's not the firs time the hierarchic file system was invented). Why didn't later computers reuse its design and concepts? For starter, Multics was designed to on a modified GE-600 mainframe with customized hardware. Nobody else in the world has the same machine.

It's why it's crucial to perverse any remaining historical materials. Otherwise we won't even know even their existence.

Post reply on HN