4 ms·

As I recalled, you wrote channel instructions, or chains of channel instructions, as "CCW"s (Channel Command Words), which you dispatched to the channels via a

As I recalled, you wrote channel instructions, or chains of channel instructions, as "CCW"s (Channel Command Words), which you dispatched to the channels via a "SIO" or "SIOF" instruction (Start I/O, or Start I/O Fast). Once the operation started, the SIO(F) returned to you and the channel operated asynchronously from the CPU, moving the data directly in or out of memory. I think SIOF returned as soon as the channel received the instruction, whereas SIO waited for the instruction actually began. So the channel actually added as sort of co-processor with the same access to memory as other CPUS. I'm pretty sure the channel could use virtual addresses, but the memory of course had to be fixed (pagefixed) during the operation.

stcredzero 7y ago
How about another set of registers, which can be written by one CPU, and read by the others? Could channels be implemented as co-processors with access to memory, going through the cache? I know there are instructions to fix cache lines. I suppose some of this could be accomplished by compilers on current hardware, if they had information about CPU cores being targeted.
- MaxBarraclough 7y ago
  > How about another set of registers, which can be written by one CPU, and read by the others? The L3 cache is doing something similar. Whatever you come up with has to cope with each core implementing out-of-order execution, so it can't be both trivially simple and ultra-fast. The L2 and L1 caches are more local to the particular core, and so are faster. More generally, it seems to me unlikely that it would ever make sense to trade off against per-core performance. > I suppose some of this could be accomplished by compilers on current hardware, if they had information about CPU cores being targeted. Are we talking about a new software abstraction, or a performance-enhancement on existing hardware? The latter seems unlikely to me - the parallelism folks would've thought of it.

stcredzero 7y ago

How about another set of registers, which can be written by one CPU, and read by the others? Could channels be implemented as co-processors with access to memory, going through the cache? I know there are instructions to fix cache lines. I suppose some of this could be accomplished by compilers on current hardware, if they had information about CPU cores being targeted.

MaxBarraclough 7y ago
> How about another set of registers, which can be written by one CPU, and read by the others? The L3 cache is doing something similar. Whatever you come up with has to cope with each core implementing out-of-order execution, so it can't be both trivially simple and ultra-fast. The L2 and L1 caches are more local to the particular core, and so are faster. More generally, it seems to me unlikely that it would ever make sense to trade off against per-core performance. > I suppose some of this could be accomplished by compilers on current hardware, if they had information about CPU cores being targeted. Are we talking about a new software abstraction, or a performance-enhancement on existing hardware? The latter seems unlikely to me - the parallelism folks would've thought of it.