News for hackers. Stuff that matters.
Re:Mill CPU Inter-Process Communication by convolvatron on Sunday October 08, 2017 @06:42PM (#15430444)
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

Re:Mill CPU Inter-Process Communication by Taniwha on Sunday October 08, 2017 @08:11PM (#15430731)
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

Re:Mill CPU Inter-Process Communication by menage on Sunday October 08, 2017 @08:48PM (#15430868)
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.
Re:Mill CPU Inter-Process Communication by deepnotderp on Sunday October 08, 2017 @11:29PM (#15431402)
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.
Re:Mill CPU Inter-Process Communication by convolvatron on Sunday October 08, 2017 @11:48PM (#15431460)
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)

Re:Mill CPU Inter-Process Communication by deepnotderp on Sunday October 08, 2017 @11:52PM (#15431469)
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.

Re:Mill CPU Inter-Process Communication by neerajsi on Monday October 09, 2017 @04:06AM (#15432205)
Wrt smart peripherals, probably all it means is that you need an IOMMU if you don't want to have to trust your drivers.
Re:Mill CPU Inter-Process Communication by igodard on Tuesday October 10, 2017 @04:24PM (#15445039)
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.

Re:Mill CPU Inter-Process Communication by convolvatron on Sunday October 08, 2017 @08:58PM (#15430921)
it was at the end in the questions