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

41–50 of 110 posts

Re: The RISC Deprogrammer

#41

Post by erwan577 »

pvg wrote: post #26
erwan577 wrote: post #20

One of the idea I take from the piece is that CPU design success is intimately tied to the software ecosystem of the day and Memory Management Units were a big thing for C langage multitasking. I wonder if Rust or similar could make the MMU transistors and energy budget redondant. Disclaimer: I am a 68k fan.

Memory Management Units were a big thing for C langage multitasking. How do you figure? The article outlines MMU development since well before C, it's not like people came up with memory protection because of C.

I was a user at the time, and also a reader of many computing magazines.

GUI environments of the 80s all brought multitasking with them, and system stability was mediocre to very bad... All writers pointed to memory protection as the cure of all this. See also Mac os history for a more detailed usecase.

Rising software size and complexity made the industry abandon assembly programming for higher level languages and for GUI apps this quickly meant C/C++.

Re: The RISC Deprogrammer

#42

Post by erwan577 »

flohofwoe wrote: post #37
adwn wrote: post #34

Earlier quoted context omitted.

> I wonder if Rust or similar could make the MMU transistors and energy budget redondant. No, those concerns are completely independent of each other. Rust's memory safety protects from accidentally accessing the wrong memory within the same address space, while the MMU protects against accessing (accidentally or intentionally) any memory in other address spaces. In addition, the address translation done by the MMU h…

> ...accessing the wrong memory within the same address space On systems without MMU there's only one shared address space (like on the Amiga, you only had lightweight processes/threads called Exec Tasks which all ran in the same global address space). Rust could definitely help to isolate memory accesses of applications that all run in the same address space.

Rust should help with the stability issues that plagued the 80s/90s before fully enforced memory protection. Now I wonder if MMU really brings other benefits.

In my latest workstation, I do not use virtual memory to use the disk as extra memory for my running software, i use compressed memory as a disk cache. 30 years of progress has changed the requirements and usecases. Maybe the MMU will survive in a different form that would require a new name.

I read the 4k virtual memory pages and TLB caches are becoming a performance bottleneck so this needs to be redesigned anyway.

Re: The RISC Deprogrammer

#43

Post by segfaultbuserr »

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 PDP-11 did not even have an FPU. It only appeared on later models: on low-end machines a simplified FPU version was available for separate purchase with limited functionalities, and only high-end models had the full FPU. On a system without FPU installed, you basically don't need to worry about "PDP-endian", it's a pure little-endian machine. But for convenience, the Unix C compiler always stored long integers in PDP-endian to avoid swapping endians. Because the same Unix and C software ran on all machines with or without FPU, all Unix programmers needed to worry about it, thus the PDP-endian folklore.

But why did the PDP-11 FPU use this strange format? @aka_pugs from Twitter did some digging, and found the PDP-endian was already in used as a softfloat format by DEC's PDP-11 Fortran compiler. So the FPU was made compatible with that...

Re: The RISC Deprogrammer

#44

Post by klelatti »

noobermin wrote: post #31
erwan577 wrote: post #20

One of the idea I take from the piece is that CPU design success is intimately tied to the software ecosystem of the day and Memory Management Units were a big thing for C langage multitasking. I wonder if Rust or similar could make the MMU transistors and energy budget redondant. Disclaimer: I am a 68k fan.

We had a "sample" of this, at least according to the author, although it was in a less savory direction from those who care about memory safety and things like that: The M1 was optimized to run js shit faster apparently, which he claims is why the CPU is better for mobile machines (macbooks). Supposedly rust is too new for a new arch to design around it. Tbh, and may be this is just the limits of my imagination, but…

Here is the JS reference in the article.

> For example, they added a lot of great JavaScript features, cognizant of the ton of online and semi-offline apps that are written in JavaScript. In contrast, Intel attempts to optimize a chip simultaneously for laptops, desktops, and servers, leading poorly optimizations for laptops.

Now there is a JS feature in the M1. It's the FJCVTZS instruction "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" which ensures this conversion follows the JS specification. [1]

And this does indeed improve JS performance for Arm CPUs. But why does JS behave this way? Because it was specified to follow what x86 does!

So to say that 'M1 is optimised for JS but x86 isn't etc' is just plain wrong.

Also: - Apple didn't do it Arm did. - It has nothing whatsoever to do with memory management.

[1] https://stackoverflow.com/questions/50966676/why-do-arm-chip...

Re: The RISC Deprogrammer

#45

Post by jabl »

noobermin wrote: post #33
jabl wrote: post #25

Earlier quoted context omitted.

Hypothetically, sure. One can imagine a system getting rid of virtual memory, and instead using e.g. some kind of capability system to prevent programs from reading memory they're not allowed to. In reality, there's so much software that assumes each process gets its own private address space that I find it very hard to imagine what a transition to this new MMU-less world would look like. Maybe something CHERI-like a…

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.

Re: The RISC Deprogrammer

#46

Post by Someone »

erwan577 wrote: post #20

One of the idea I take from the piece is that CPU design success is intimately tied to the software ecosystem of the day and Memory Management Units were a big thing for C langage multitasking. I wonder if Rust or similar could make the MMU transistors and energy budget redondant. Disclaimer: I am a 68k fan.

> I wonder if Rust or similar could make the MMU transistors and energy budget redundant.

The MMU does two things:

- shields processes from each other

- creates the illusion that the machine has more memory that in it has

To do away with the former without giving up its benefits, the CPU would, somehow, have to know the code it runs won’t interfere with other processes. It could trust a particular compiler to produce code that’s safe, and rust could provide such a compiler, but then, the CPU would have to prevent Mallory (https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characte...) from producing a binary that he claims was created by that rust compiler, but isn’t.

One way would be to make the CPU run that compiler. The CPU then would not be able to run anything else than code compiled by that rust compiler. That may be seen as prohibitive.

Even if it isn’t, the CPU probably would not want to commit to being tied to one particular compiler. Checking that the actual output of the compiler is safe may be easier. That’s one reason why byte codes were invented. They decrease the coupling between programming language and CPU, allowing evolution of a compiler (often even compiler_s_, supporting multiple languages) independent of the byte code.

So, yes, you could use rust for the first item, but you probably don’t want to. Technologies such as the JVM, Microsoft CLR, or WASM are more suited for that kind of stuff.

Also, if you want to give processes the illusion that the machine has more memory that in it has, you would still need a MMU. It could be a bit simpler, but it still would be a MMU.

Re: The RISC Deprogrammer

#47

Post by KingOfCoders »

flohofwoe wrote: post #38
abiloe wrote: post #18

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

> 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 registers). That said, "Z80 assembly language subroutines" is my most precious computer book still, the one I would take through the apocalypse.

Re: The RISC Deprogrammer

#48

Post by kragen »

Taniwha wrote: post #7

completely ignores the reason why RISC architectures took over .... the L1 I-cache moved on chip, suddenly the main reason for complex instruction encodings went away

While that was very important, wasn't the ARM2 with no cache significantly faster than contemporary CISC processors like the 80386 with no cache?

I know Dhrystone isn't real but https://www.realworldtech.com/arms-race/2/ says an 8 MHz Archimedes got 4901 Dhrystones per second to the 16-MHz 386's 3626 Dhrystones per second. https://en.wikipedia.org/wiki/Instructions_per_second gives the 8-MHz ARM2 4 [Dhrystone] MIPS at 8 MHz and the 16-MHz "i386DX" 2.15 MIPS at 16 MHz. In fact, the cacheless ARM2 even beat the CISC 68020, which did have a tiny cache!

Also, I think squished RISC instruction encodings like Thumb, MIPS16, and RVC seem pretty competitive with popular CISCs on code density; RVC even seems to best them. So even if your data access is competing with instruction fetch for memory bandwidth because you don't have an icache, you'd probably still get more instructions per memory cycle out of RVC than out of i386 or AMD64.

Re: The RISC Deprogrammer

#49

Post by ufo »

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…

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.

Re: The RISC Deprogrammer

#50

Post by kragen »

pvg wrote: post #26
erwan577 wrote: post #20

One of the idea I take from the piece is that CPU design success is intimately tied to the software ecosystem of the day and Memory Management Units were a big thing for C langage multitasking. I wonder if Rust or similar could make the MMU transistors and energy budget redondant. Disclaimer: I am a 68k fan.

Memory Management Units were a big thing for C langage multitasking. How do you figure? The article outlines MMU development since well before C, it's not like people came up with memory protection because of C.

PoohBear, it's because Smalltalk, Oberon, and J2ME systems didn't need MMUs. People came up with MMUs because of low-level languages, a category which includes assembly and C. But we're just rehearsing debates that are half a century old.

(On the other hand, the B5000 had hardware memory protection despite being programmed in Algol. The B5000 inspired Smalltalk, which inspired Oberon and Java. But its memory protection didn't use an MMU.)

Post reply on HN