4 ms·

Mac OS and Atari ST had both Motorola 680x0 CPUs. So both had a flat address space.

by vardump 3y ago

rjsw 3y ago
Only one of them ran an operating system that exposed it to applications.
- icedchai 3y ago
  Also, we should mention that early Mac OS "borrowed" the top 8 bits of a 32-bit pointer for operating system use: https://lowendmac.com/2015/32-bit-addressing-on-older-macs/ https://lowendmac.com/2015/32-bit-addressing-on-older-macs/
- speed_spread 3y ago
  Motorola 68000 CPU had no MMU so OS and applications ran in the same address space so anyone could do anything and a lose pointer could crash the whole box at anytime. This is true for all early Mac, Amiga and Atari. 68020 CPU was the same. There was an MMU only from the 68030 but still many OS didn't take advantage of it upon release.
  - rjsw 3y ago
    Mac OS put code into segments that could be moved around, Atari ST TOS didn't do this.
    - duskwuff 3y ago
      > Mac OS put code into segments that could be moved around Huh? CODE segments were never relocatable at runtime. That'd be absurd.
      - canucker2016 3y ago
        from Apple Macintosh Segment Manager docs - https://developer.apple.com/library/archive/documentation/mac/pdf/Processes/Segment_Manager.pdf https://developer.apple.com/library/archive/documentation/ma...: "Although needed code segments are loaded into memory automatically, it is your application’s responsibility to unload any segments that are not currently being used. The Segment Manager provides a single procedure, UnloadSeg, that you can call to unload a segment. To unload a segment is simply to unlock it. By unlocking unneeded segments, you allow them to be relocated or purged if necessary to accommodate a later memory-allocation request. Thus, using the Segment Manager to unload unneeded segments is one important aspect of an efficient memory-management policy."
        duskwuff 3y ago
        That bit of the documentation was... misguided. Relocating code segments was incompatible with many popular C runtimes (typically because CREL/DREL relocations were applied to the segment at load time, and there was no way to rerun that after a segment was moved), and was dangerous even if that wasn't the case (because stray references to the old location would often persist, e.g. as function pointers). Later on in the 68k Mac OS lifecycle, compilers figured out how to bypass the 32k segment limit, and would often compile the entire application to a single CODE resource, sometimes with auxiliary resources for embedded libraries. There was certainly no unloading those.
        canucker2016 3y ago
        Not misguided when the Macintosh was initially introduced with 128K of RAM. All the articles I've read about Apple Mac software development state that 68K assembly language and Pascal were used for software development. So the C compilers released later had bugs if they couldn't ignore/handle an UnloadSeg() call on one of their generated CODE segments. By the time I got into Mac development, THINK C and MPW C didn't seem to have any problems with CODE segments.
    - Someone 3y ago
      They were never moved around, but could be unloaded manually and read back from (floppy) disk at another memory location.
  - snvzz 3y ago
    68000 had no MMU and didn't support one, due to inability to recover from bus error. 68010 supported an MMU, so did 68020. 68030 bundled a MMU (except EC variants).

Mac OS and Atari ST had both Motorola 680x0 CPUs. So both had a flat address space.

rjsw 3y ago

Only one of them ran an operating system that exposed it to applications.

icedchai 3y ago
Also, we should mention that early Mac OS "borrowed" the top 8 bits of a 32-bit pointer for operating system use: https://lowendmac.com/2015/32-bit-addressing-on-older-macs/ https://lowendmac.com/2015/32-bit-addressing-on-older-macs/
speed_spread 3y ago
Motorola 68000 CPU had no MMU so OS and applications ran in the same address space so anyone could do anything and a lose pointer could crash the whole box at anytime. This is true for all early Mac, Amiga and Atari. 68020 CPU was the same. There was an MMU only from the 68030 but still many OS didn't take advantage of it upon release.
- rjsw 3y ago
  Mac OS put code into segments that could be moved around, Atari ST TOS didn't do this.
  - duskwuff 3y ago
    > Mac OS put code into segments that could be moved around Huh? CODE segments were never relocatable at runtime. That'd be absurd.
    - canucker2016 3y ago
      from Apple Macintosh Segment Manager docs - https://developer.apple.com/library/archive/documentation/mac/pdf/Processes/Segment_Manager.pdf https://developer.apple.com/library/archive/documentation/ma...: "Although needed code segments are loaded into memory automatically, it is your application’s responsibility to unload any segments that are not currently being used. The Segment Manager provides a single procedure, UnloadSeg, that you can call to unload a segment. To unload a segment is simply to unlock it. By unlocking unneeded segments, you allow them to be relocated or purged if necessary to accommodate a later memory-allocation request. Thus, using the Segment Manager to unload unneeded segments is one important aspect of an efficient memory-management policy."
      - duskwuff 3y ago
        That bit of the documentation was... misguided. Relocating code segments was incompatible with many popular C runtimes (typically because CREL/DREL relocations were applied to the segment at load time, and there was no way to rerun that after a segment was moved), and was dangerous even if that wasn't the case (because stray references to the old location would often persist, e.g. as function pointers). Later on in the 68k Mac OS lifecycle, compilers figured out how to bypass the 32k segment limit, and would often compile the entire application to a single CODE resource, sometimes with auxiliary resources for embedded libraries. There was certainly no unloading those.
        canucker2016 3y ago
        Not misguided when the Macintosh was initially introduced with 128K of RAM. All the articles I've read about Apple Mac software development state that 68K assembly language and Pascal were used for software development. So the C compilers released later had bugs if they couldn't ignore/handle an UnloadSeg() call on one of their generated CODE segments. By the time I got into Mac development, THINK C and MPW C didn't seem to have any problems with CODE segments.
  - Someone 3y ago
    They were never moved around, but could be unloaded manually and read back from (floppy) disk at another memory location.
- snvzz 3y ago
  68000 had no MMU and didn't support one, due to inability to recover from bus error. 68010 supported an MMU, so did 68020. 68030 bundled a MMU (except EC variants).