[ ENORELEVANCE ]

> The Mac had to use PIC - after all, the original system was based on the
> Motorola 68000, and an MMU was an extra-cost chip that they felt they didn't
> need.

They could have gotten by with something MMU-like, but not a real MMU
as we know it.  The 68000 coudln't restart instructions, and therefore
to do real Virtual Memory MMU functionality you'd need the gross
dual-68000 hack (as i'm sure you're aware).  I suppose they could have
done something like linking CODE segments at fixed addresses, and
loading the pseudo-MMU (really just some circuitry to do translation)
to point the right addresses to the right memory when the CODE
segments were locked (rather than locking them then fixing up the CODE
0 jump table)...  However, given the (beautiful, in my opinion)
simplicity of what they did entirely in software, i'd say their
decision made sense in context.

Of course, over time, context changed.  8-)

Still, i'd say that a smart application developer could get a much,
much better memory footprint from the CODE scheme than they could
using e.g. most UNIXes' VM systems...  (Of course, now memory is
cheap, too... 8-)


> You might find this Technical Note, entitled "Managerial Abuse" interesting:
> 
> http://devworld.apple.com/ngs/lpp/adrpub/docs/dev/technotes/ov/ov_08.html
> 
> It points out some traps that programmers can fall into by abusing
> the various facilities that the MacOS provides, including the
> "Resource Manager."

*chuckle* And in my time as a Mac programmer, I abused three of the
four facilities they mention, in almost exactly the ways described.
8-)


chris