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

Linear Address Spaces: Unsafe at any speed (2022)

queue.acm.org

Post reply on HN
Print view View original

141–150 of 183 posts

Re: Linear Address Spaces: Unsafe at any speed (2022)

#141

Post by pjmlp »

SulphurCrested wrote: post #81
mpweiher wrote: post #45

> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? Because the attempts at segmented or object-oriented address spaces failed miserably. > Linear virtual addresses were made to be backwards-compatible with tiny computers with linear physical addresses but without virtual memory. That is false. In the Intel World, we first had the iAPX…

The Burroughs large system architecture of the 1960s and 1970s (B6500, B6700 etc.) did it. Objects were called “arrays” and there was hardware support for allocating and deallocating them in Algol, the native language. These systems were initially aimed at businesses (for example, Ford was a big customer for such things as managing what parts were flowing where) I believe, but later they managed to support FORTRAN wi…

It still exists today, as Unisys ClearPath MCP.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#142

Post by suspended_state »

imtringued wrote: post #139
suspended_state wrote: post #93

Earlier quoted context omitted.

> Code has to have addresses for calls and branches. Does it mean that at that level an address has to be an offset in a linear address space? If you have hardware powerful enough to make addresses abstract, couldn't also provide the operations to manipulate them abstractly?

This is probably the worst possible way to implement a processor. Instead of just bumping the instruction pointer by one or an offset, you now need to have code labels in your processor and a way to efficiently look them up. goto "exit" means the processor needs to have a lookup table of all the possible nodes in the computational graph. Calling a function requires a global look up table. How is that table implemente…

What I meant, and indeed it was poorly explained, is that an address shouldn't be just an integer freely manipulable by any instruction. The microcode will obviously know how to an manipulate an address, but the ISA as a whole doesn't have to, and in fact shouldn't, with the exception of a few specific instructions. What I am advocating is that addresses should constitute a separate type, which isn't a simple alias to integers. I think that this is what capabilities are about.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#143

Post by adgjlsfhk1 »

bluGill wrote: post #95
adgjlsfhk1 wrote: post #83

Earlier quoted context omitted.

while that's true, CPUs already have automatically managed caches. it's not too much of a stretch to imagine a world in which RAM is automatically managed as well and you don't have a distinction between RAM and persistent storage. in a spinning rust world, that never would have been possible, but with modern nvme, it's plausible.

Cpus manage it, but ensuring your data structures are friendly to how they manage caches is one of the keys to fast programs - which some of us care about.

Absolutely! And it certainly is true that for the most performance optimized codes, having manual cache management would be beneficial, but on the CPU side, at least, we've given up that power in favor of a simpler programming model.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#144

Post by yvdriess »

mpweiher wrote: post #135
yvdriess wrote: post #132

Earlier quoted context omitted.

> > Linear virtual addresses were made to be backwards-compatible with tiny computers with linear physical addresses but without virtual memory. > That is false. In the Intel World, we first had the iAPX 432, which was an object-capability design. To say it failed miserably is overselling its success by a good margin. That's not refuting the point he's making. The mainframe-on-chip iAPX family (and Itanium after) die…

The way you selectively quoted: yes, you removed the refutation. And regarding the iAPX 432: it was slow in large part due to the failed object-capability model. For one, the model required multiple expensive lookups per instruction. And it required tremendous numbers of transistors, so many that despite forcing a (slow) multi-chip design there still wasn't enough transistor budget left over for performance enhancing…

I agree on the part of the opportunity cost and that given the transistor budgets of the time a simpler design would have served better.

I fundamentally disagree on putting the majority of the blame on the object memory model. The problem was that they were compounding the added complexity of the object model with a slew of other unnecessary complexities. They somehow did find the budget to put the first full IEEE floating point unit on the execution unit, implemented a massive[1] decoder and microcode for the bit-aligned 200+ instruction set and interprocess communication. The expensive lookups per instructions had everything to do with cutting caches and programmable registers, not any kind of overwhelming complexity to the address translation.

I strongly recommend checking the "Performance effects of architectural complexity in the Intel 432" paper by Colwell that I linked in the parent.

[1] die shots: https://oldbytes.space/@kenshirriff/110231910098167742

Re: Linear Address Spaces: Unsafe at any speed (2022)

#145

Post by gpderetta »

inkyoto wrote: post #65
mpweiher wrote: post #45

> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? Because the attempts at segmented or object-oriented address spaces failed miserably. > Linear virtual addresses were made to be backwards-compatible with tiny computers with linear physical addresses but without virtual memory. That is false. In the Intel World, we first had the iAPX…

> Because the attempts at segmented or object-oriented address spaces failed miserably. > That is false. In the Intel World, we first had the iAPX 432, which was an object-capability design. To say it failed miserably is overselling its success by a good margin. I would further posit that segmented and object-oriented address spaces have failed and will continue to fail for as long as we have a separation into two di…

I think seamless persistent storage is also bound to fail. There are significant differences on how we treat ephemeral objects in programs and persistent storage. Ephemeral objects are low value, if something goes wrong we can just restart and recover from storage. Persistent storage is often high value, we make significant effort to guarantee its consistency and durability even in the presence of crashes.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#146

Post by suspended_state »

cryptonector wrote: post #112
suspended_state wrote: post #93

Earlier quoted context omitted.

> Code has to have addresses for calls and branches. Does it mean that at that level an address has to be an offset in a linear address space? If you have hardware powerful enough to make addresses abstract, couldn't also provide the operations to manipulate them abstractly?

Is each branch-free run of instructions an object (which in general will be smaller than "function" or "method" objects) that can be abstracted? How does one manage locality ("these objects are the text of this function")? Maybe one compromises and treats the text of a function as linear address space with small relative offsets. Of course, other issues will crop up. You can't treat code as an array, unless it's an a…

The linking stage could perhaps be performed at process launch by a privileged task?

See this comment thread: https://news.ycombinator.com/item?id=46494183

Isn't a virtual ISA like an intermediate representation? It doesn't have to include static addresses, only symbolic references, which could be resolved at launch time.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#147

Post by cryptonector »

suspended_state wrote: post #146
cryptonector wrote: post #112

Earlier quoted context omitted.

Is each branch-free run of instructions an object (which in general will be smaller than "function" or "method" objects) that can be abstracted? How does one manage locality ("these objects are the text of this function")? Maybe one compromises and treats the text of a function as linear address space with small relative offsets. Of course, other issues will crop up. You can't treat code as an array, unless it's an a…

The linking stage could perhaps be performed at process launch by a privileged task? See this comment thread: https://news.ycombinator.com/item?id=46494183 Isn't a virtual ISA like an intermediate representation? It doesn't have to include static addresses, only symbolic references, which could be resolved at launch time.

> The linking stage could perhaps be performed at process launch by a privileged task?

This gets expensive.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#148

Post by bluGill »

adgjlsfhk1 wrote: post #143
bluGill wrote: post #95

Earlier quoted context omitted.

Cpus manage it, but ensuring your data structures are friendly to how they manage caches is one of the keys to fast programs - which some of us care about.

Absolutely! And it certainly is true that for the most performance optimized codes, having manual cache management would be beneficial, but on the CPU side, at least, we've given up that power in favor of a simpler programming model.

Part of giving up is what is correct changes too fast. Attempts to do this manually often got great results for a year and then made things worse for the next generation of CPU that did things differently. Anyone who needs manual control thus would need to target a specific CPU and be willing to spend hundreds of millions every year to update the next CPU - there is nobody who is willing to spend that much. The few who would be are better served by putting the important thing into a FPGA which is going to be faster yet for similar costs.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#149

Post by marcosdumay »

mike_hearn wrote: post #124
Veserv wrote: post #62

Earlier quoted context omitted.

You are describing a memory protection unit (MPU). Those are common in low-resource contexts that are too simple to afford a full memory management unit (MMU). The problem with scaling that up, especially in general-purpose environments with dynamic process creation, is fragmentation of the shared address space. You need a contiguous chunk for whatever object you are allocating. Other allocations fragment the address…

Or you run everything with a compacting GC.

Well, unless you are ok with excluding software written in many common programming languages from your platform, that's not really an option.

It may be ok for embedded systems, but those recently have been evolving on the opposite direction.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#150

Post by cryptonector »

suspended_state wrote: post #93
mikewarot wrote: post #84

Earlier quoted context omitted.

Code has to have addresses for calls and branches. Debuggers need to be able to control it all.

> Code has to have addresses for calls and branches. Does it mean that at that level an address has to be an offset in a linear address space? If you have hardware powerful enough to make addresses abstract, couldn't also provide the operations to manipulate them abstractly?

Another thing is that array addressing is tricky. You need to support arrays, but then how do you construct pointers to individual elements of the arrays? The cleanest option is to not allow that and force the programmer to always pass around the pointer to the array and an index. The same applies to slices. This definitely makes life harder for porting existing codebases or making existing languages work.
Post reply on HN