4 ms·

My wife's parents met while working on system software for Stretch. From the stories they've told it sounds like it was quite a beast even by the standards of i

My wife's parents met while working on system software for Stretch. From the stories they've told it sounds like it was quite a beast even by the standards of its day. IIRC, the I/O processor was incapable of running independently, so programmers had to add special instructions in the middle of their own code to give it cycles. Ick.

jacquesm 7y ago
That's a cooperative synchronous bus, something quite common at the time. It's a bit like a 'yield' instruction in a cooperative multitasking environment.
- notacoward 7y ago
  It's a bit more than that. There's usually quite a bit of flexibility in when to yield, and the consequences might not be that bad. These instructions had to be issued in a very timely way, lest the whole system would come crashing down. Was it unique in that regard? Perhaps not, though "common" is a bit misleading when the computing landscape at the time was so small and fragmented. The difference is that other architectures might have shared one or two misfeatures with Stretch out of unfortunate necessity, but the Stretch designers seemed determined to collect the entire set and then expand on it. I'd guess that, like some projects I've been on, it was a case of one powerful or well connected group of people pushing as much complexity as possible onto another. So it's probably related to the "project management failure" sub-thread.
  - ncmncm 7y ago
    Requiring periodic yields in user code strikes me as indicating a dedication to simplicity. It was no great burden to add a few instructions to a program, and it apparently saved them from needing to implement a forced, transparent context switch mechanism.
    - notacoward 7y ago
      I think you're misunderstanding what we're talking about. This wasn't in user code; it was in the OS ("MCP") itself. It wasn't a few instructions that could be placed at convenient points in the control flow; it was every N instructions when I/O was active. Among other difficulties, that meant accounting for that had to be part of even minor code changes. The people actually doing it certainly didn't think it was simple or "no great burden" as you suggest. Simple would have been an I/O unit that could run independently of the main CPU, as in practically every machine designed since - including the 360 which was designed by the same person. Even he apparently recanted that decision. So yeah, it's "a bit" like yield, but only in the sense that a Cessna and an F-22 are "a bit" alike. I've done low-level work on multiple RISC processors that had all sorts of exposed-pipeline and delegated-to-software functionality (e.g. TLB handling on MIPS) in the name of simplicity, and I've even enjoyed it somewhat, but I'm still glad I never had to work on anything as "raw" as Stretch.

jacquesm 7y ago

That's a cooperative synchronous bus, something quite common at the time. It's a bit like a 'yield' instruction in a cooperative multitasking environment.

notacoward 7y ago
It's a bit more than that. There's usually quite a bit of flexibility in when to yield, and the consequences might not be that bad. These instructions had to be issued in a very timely way, lest the whole system would come crashing down. Was it unique in that regard? Perhaps not, though "common" is a bit misleading when the computing landscape at the time was so small and fragmented. The difference is that other architectures might have shared one or two misfeatures with Stretch out of unfortunate necessity, but the Stretch designers seemed determined to collect the entire set and then expand on it. I'd guess that, like some projects I've been on, it was a case of one powerful or well connected group of people pushing as much complexity as possible onto another. So it's probably related to the "project management failure" sub-thread.
- ncmncm 7y ago
  Requiring periodic yields in user code strikes me as indicating a dedication to simplicity. It was no great burden to add a few instructions to a program, and it apparently saved them from needing to implement a forced, transparent context switch mechanism.
  - notacoward 7y ago
    I think you're misunderstanding what we're talking about. This wasn't in user code; it was in the OS ("MCP") itself. It wasn't a few instructions that could be placed at convenient points in the control flow; it was every N instructions when I/O was active. Among other difficulties, that meant accounting for that had to be part of even minor code changes. The people actually doing it certainly didn't think it was simple or "no great burden" as you suggest. Simple would have been an I/O unit that could run independently of the main CPU, as in practically every machine designed since - including the 360 which was designed by the same person. Even he apparently recanted that decision. So yeah, it's "a bit" like yield, but only in the sense that a Cessna and an F-22 are "a bit" alike. I've done low-level work on multiple RISC processors that had all sorts of exposed-pipeline and delegated-to-software functionality (e.g. TLB handling on MIPS) in the name of simplicity, and I've even enjoyed it somewhat, but I'm still glad I never had to work on anything as "raw" as Stretch.