doug@terak.UUCP (Doug Pardee) (03/21/85)
> Furthermore, the 360/67, which was a 65 with address translation > phardware to allow paging, had 32 bit addressing in 1967, only three years > after the 360 architecture was designed. The 67 was an RPQ (a one-off) developed for Project MAC at MIT (the system that was to pioneer the "timesharing" concept), in competition against General Electric. IBM did indeed sell more than one, but it was never a "production" version of the System/360. (GE won the MAC bid). Some other off-the-wall RPQ 360's: models 25, 44, 75, 85, 91, 9020. > you can ask why the software wasn't written to be upgradable to 32 > bit addresses so at least it might run on the 67. OS/360 was "completed" before the 360/67 was even thought of. And when the 67 was conceived, it was designed expressly for Project MAC, and was intended to run only the TSS timesharing system. In any event, the 67 could and did run OS/360 anyway, trash in the upper bits and all. > There was also an article on the addressing scheme, in which it looked to me > like they sincerely believed that their base-displacement addressing scheme > would get them the advantages of virtual memory without the cost of building a > DAT box. Without having seen the article, I would be surprised if "virtual memory" was on their minds. The addressing scheme allows considerable flexibility in where modules are initially loaded in memory. This would appear to reduce "checkerboarding" of available memory space, a serious problem in earlier multiprogrammed systems. In practice though, it turned out that procedure code was no longer the main user of core, and "scatter loading" (where parts of the code are loaded all over the place) never became popular. And the data areas ended up being limited to 4K segments (that should make the Intel iAPX86 programmers smile). -- Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug