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

71–80 of 110 posts

Re: The RISC Deprogrammer

#71

Post by childintime »

kragen wrote: post #51
childintime wrote: post #39

Strongly opinionated with a real message, I loved it. Through the RISC story we pay a cultural debt we owe to RISC. It is story telling, about a time long gone, and the tale is mythical in nature. In opposition to the myth, as the article states, RISC by itself is no longer an ideal worth pursuing. This is relevant to the other Big Myth of our tech times, the Unix Story, and by extension to Linux. UNIX is mythical, h…

Listen, if you write a software system that puts more power at my disposal than Unix does, I'm happy to try it. But I suspect the Unix design has more wisdom in it than you think, because when I've tried to do better, even with the benefit of hindsight, I've always fallen short.

Thanks for replying, others just treat me like a troll and downvote, beholden to the myth that Linux is the gold standard. That's exactly the willful blindness I am talking about.

You talk about network effects, as Linux is the only game in town, currently. Implicitly I talk about that too, that's why I mention Linus, I expect leadership. Why develop Linux? There's not much ROI, unless change is the keyword.

Indeed the challenge is to create a new operating system suited to the demands that exist today. Fuchsia is a step, the only thing I can point to right now, but it is hardly accessible.

Note that Android works to overcome the need for a system administrator. That's because Linux works against what it needs to be: an invisible OS. The most prolific use of Linux isn't really a success story.

Furthermore, you suggest "power". Perhaps you talk about piping and shell tools. These are indeed part of the myth, good ideas but, pardon me, terribly executed. They do not compose, they are not scalable. Again because of the time frame they were conceived in, this was impossible. But that is the refrain throughout. As a result everything is just messy, resulting in huge time sinks.

Indeed I hope to one day have the disposition to truly go back to basics, and make a runtime, a substrate if you will, that will run fully inspectable code, with an execution that can be visualized, questioned and reasoned about. That way users and tools can adjust any process, repeatedly, or just once. Incrementally so.

All machine details would be hidden, and that includes (obviously, for me) everything binaries: compilation, ABI's. Something current OSes (not counting the Web) don't do.

In the end the best OS is an invisible OS.

Re: The RISC Deprogrammer

#72

Post by thechao »

kragen wrote: post #51
childintime wrote: post #39

Strongly opinionated with a real message, I loved it. Through the RISC story we pay a cultural debt we owe to RISC. It is story telling, about a time long gone, and the tale is mythical in nature. In opposition to the myth, as the article states, RISC by itself is no longer an ideal worth pursuing. This is relevant to the other Big Myth of our tech times, the Unix Story, and by extension to Linux. UNIX is mythical, h…

Listen, if you write a software system that puts more power at my disposal than Unix does, I'm happy to try it. But I suspect the Unix design has more wisdom in it than you think, because when I've tried to do better, even with the benefit of hindsight, I've always fallen short.

At this point, I think "Unix" maps cleanly onto a Chesterton's Gate.

Re: The RISC Deprogrammer

#73

Post by kens »

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 bit to make addition work. As a result, it was little-endian.

CTC talked to Intel and Texas Instruments to see if the processor could be put onto VLSI chips to replace the board of TTL chips. Texas Instruments produced the TMX 1795 processor, shortly followed by the Intel 8008, both processors cloning the Datapoint 2200's instruction set and architecture including little-endian. CTC rejected both processors and stuck with TTL. TI couldn't find another customer for the TMX 1795 and it vanished from history. Intel successfully marketed the 8008 as a general-purpose microprocessor. Its architecture was copied for the 8080 and then modified for the 16-bit 8086, leading to the x86 architecture that rules the desktop and server market. As a result, x86 has the little-endian architecture and other features of the Datapoint 2200. I consider the Datapoint 2200 to be one of the most influential processors ever, even though it's almost completely forgotten.

Re: The RISC Deprogrammer

#74

Post by kragen »

childintime wrote: post #71
kragen wrote: post #51

Earlier quoted context omitted.

Listen, if you write a software system that puts more power at my disposal than Unix does, I'm happy to try it. But I suspect the Unix design has more wisdom in it than you think, because when I've tried to do better, even with the benefit of hindsight, I've always fallen short.

Thanks for replying, others just treat me like a troll and downvote, beholden to the myth that Linux is the gold standard. That's exactly the willful blindness I am talking about. You talk about network effects, as Linux is the only game in town, currently. Implicitly I talk about that too, that's why I mention Linus, I expect leadership. Why develop Linux? There's not much ROI, unless change is the keyword. Indeed t…

There are lots of exciting options to explore!

Re: The RISC Deprogrammer

#75

Post by kragen »

sponaugle wrote: post #69
kragen wrote: post #35

Earlier quoted context omitted.

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 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 :)"

Re: The RISC Deprogrammer

#76

Post by nuc1e0n »

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 hindering the performance we could get by having better compilers? This is especially important now the transistor budget isn't nearly so flexible.

Re: The RISC Deprogrammer

#77

Post by snvzz »

jabl wrote: post #70
cesarb wrote: post #67

Earlier quoted context omitted.

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

Relative to x86 (where you need bruteforce, with complexity growing geometric to decode width), it is so cheap you could call it free.

Re: The RISC Deprogrammer

#78

Post by thethirdone »

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.

Re: The RISC Deprogrammer

#79

Post by erwan577 »

mpweiher wrote: post #40

This "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…

I strongly agree with the point the problem was that compilers weren't using these addressing modes at all

at least in the 80s microcomputer compilers were very primitive compared to what we have now which maintained a strong need for ASM. Dev tools used to be very expensive and proprietary too.

GCC started to slowly changes that starting by 1987.

So there was a time when software started to be mainly compiled high level language but using stupid compilers and CPU designers had to live with that.

Re: The RISC Deprogrammer

#80

Post by kragen »

kragen wrote: post #74
childintime wrote: post #71

Earlier quoted context omitted.

Thanks for replying, others just treat me like a troll and downvote, beholden to the myth that Linux is the gold standard. That's exactly the willful blindness I am talking about. You talk about network effects, as Linux is the only game in town, currently. Implicitly I talk about that too, that's why I mention Linus, I expect leadership. Why develop Linux? There's not much ROI, unless change is the keyword. Indeed t…

There are lots of exciting options to explore!

I missed the edit window on this but: I don't think you're going to get computers to not be messy and full of huge time sinks. That's just the nature of humanity being reflected in a silicon mirror.

I like the idea of focusing first and foremost on debuggability, on manipulating program execution histories as first-class objects. There are a huge number of interesting tradeoffs there with performance.

What I mean by "power" is that Unix makes it easy enough to do things like "interactive text chat in three lines of code" (untested, and quality at best "usable prototype" rather than "production ready")

    #!/bin/bash
    ch="${2?Usage: $0 /tmp/channelfile}"
    touch "$ch"; chmod 666 "$ch"; tail -f "$ch" &  # chat of the beast
    while read -e line; do echo " $line"; done >> "$ch"
or "which other English words might be Greek neuters, plural and all, like automaton/automata"

    grep "on$" /usr/share/dict/words | sed 's/..$/a/' | sort |
      join -
or "which directory is growing in my home directory and filling up the fucking disk"

    du -k ~ > tmp.du.1
    du -k ~ > tmp.du.2
    diff -u tmp.du.[12]
or "build the thumbnails for any images I haven't thumbnailed yet", at least as long as none of them have spaces in the names, using GNU make (untested, but adapted from real code):

    thumbnails: $(patsubst %.jpg,thumbs/%.jpg,$(wildcard *.jpg))
    thumbs/%.jpg: %.jpg
            convert -geometry 80x160 $
or "incrementally update my web pages, making an incremental backup on my server with cryptographically strong checksums" (presupposing something like http://canonical.org/~kragen/sw/dev3.git/hooks/post-update)

    git push
or "incrementally back up this directory onto my USB pendrive with cryptographically strong checksums"

    git push usbkey
or "find out what executables get transitively invoked by compiling a program with this C compiler" (warning, doesn't work if one of your files is called ENOENT)

    strace -ff -e execve cc hello.c 2>&1 | grep execve | grep -v ENOENT
or "show me a treemap of my disk usage so I can see where I can free up some space"

    k4dirstat
or "bring the focus to the URL bar of Firefox"

    xdotool search "Mozilla Firefox" windowactivate --sync key --clearmodifiers ctrl+l
or "bring up the latest version of MongoDB on my fresh laptop"

    docker run mongodb
or "find out which day we were talking about the Spanish Succession"

    grep --color -i succession 2022-10-*
or "share my screen on this server with someone else for remote pair programming"

    tmux -S /tmp/pair attach -t shared
I agree that these tools are messily executed, their scalability needs a lot of work (though don't underestimate https://adamdrake.com/command-line-tools-can-be-235x-faster-...), and their composability is not that great. Also, their usability could be vastly improved. But they're still leaps and bounds ahead of anything available on Android, in the browser, or most other alternative systems.

Simple, hackable data formats and protocols are one thing that enable this kind of thing. But I think the Unix terminal and filesystem is actually the major integration point, not pipes. Too bad they both suck. It would be nice to see successor systems that do better instead of worse; this ought to be feasible but we keep failing at it.

What would a system look like which gave you that kind of power, but to implement Valgrind-style bounds checking or profiling or AFL-style fuzzing with backtracking, and have it run with reasonable efficiency? Valgrind itself, DTrace, LuaJIT, Smalltalk-80, Emacs's "advice", videos of Symbolics Genera, aspect-oriented programming, the CLOS metaobject protocol, Maru, and the Self papers (Ungar etc.) might be places to start looking for inspiration.

Post reply on HN