Hacker News Reader

Comment by convolvatron | Hacker News Reader

watching the talk. does he not compare this to a classic segment/call gate architecture because he doesn't expect it to be a familiar reference? i'm certain he's seen it before :)

edit: i thought they managed to do all of this without segments, but at the end we hear about a special local segment with offset addressing apparently introduced just to handle children of fork()..i lost how cow can be expressed losslessly as local/global

redit: question around 1:00:00 explicitly ask this question, and he said, erroneously i think that while semantically similar this is the first time a direct hardware implementation of a call gate has been proposed

View on HN

I can think of a couple systems with hardware call gates

He also doesn't mention the word 'capability' anywhere either - this is all 1980s stuff

Ivan definitely mentioned capabilities at some point in the evening - "I'd love to build a capability architecture but I wouldn't be able to sell it" (which he's also mentioned in previous talks) but it may have been after the camera stopped rolling.

it was at the end in the questions

He does say that, but if you watch previous talks (either that or the material available) he says the primary difference (IIRC) is that you aren't supposed to segment individual data objects, but rather instead coarse grained address space segmentation, so there's really no technical difference, but it's kind of an usage difference.

i think the other (turf-like) segmentation strategy is pretty common in earlier work. i wonder about the relative efficacy from a VM implementation standpoint. particularily wrt grant/revoke on a byte range rather than a segment.

the other thing that struck me as really strange was a bit in the question period where he says that 'smart devices' (DMA?) are different from simple devices (pio?) in that they are expected to be first-class multiprocessing citizens. doesn't that imply that high-performance peripherals need to be specially designed for the Mill? (likely with a Mill core attached)

It is, it's not nearly as radical or innovative as the HN crowd would like to think, probably because it's mostly software people with a limited knowledge of 1990s era computer architecture research.

As for peripherals, I presume that would have to be handled in the drivers.

Wrt smart peripherals, probably all it means is that you need an IOMMU if you don't want to have to trust your drivers.

We have focused on the core and less on the uncore, which is why there have been no talks on I/O. The goal is for a smart peripheral to be indistinguishable from just another regular core; the Mill design is big on regularity. That implies that it has its own PLB and TLB, responds to HEYU, and supports the same IPC mechanisms, both those in the talk and those NYF.

Of course, modern peripherals don't look like that, so there will be adaptors. IBM 360 channels and CDC6600 PPs also haven't been architecturally revisited in a while.

Reply on news.ycombinator.com