4 ms·

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'

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

Taniwha 9y ago
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
- menage 9y ago
  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.
  - convolvatron 9y ago
    it was at the end in the questions
  - deepnotderp 9y ago
    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.
    - convolvatron 9y ago
      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)
      - deepnotderp 9y ago
        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.
      - neerajsi 9y ago
        Wrt smart peripherals, probably all it means is that you need an IOMMU if you don't want to have to trust your drivers.
        igodard 9y ago
        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.

Taniwha 9y ago

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

menage 9y ago
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.
- convolvatron 9y ago
  it was at the end in the questions
- deepnotderp 9y ago
  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.
  - convolvatron 9y ago
    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)
    - deepnotderp 9y ago
      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.
    - neerajsi 9y ago
      Wrt smart peripherals, probably all it means is that you need an IOMMU if you don't want to have to trust your drivers.
      - igodard 9y ago
        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.