🚀 go-pugleaf

In article <2154@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes:
>In article <2393@eagle.wesleyan.edu> rsilverman@eagle.wesleyan.edu writes:
>>Ah, for a protected-mode operating system...
>
>Seconded ! Still noone has sent me pointers to (on-line) info on
>the PMMU, so that I may hack an INIT (crude & ugly 8) that may,
>eventually, provide this in one way or another...

In this particular case, a protected mode OS wouldn't have helped much.
The program would still have died, memory would still be overwritten,
and the program would have died at the same time as without protection.

When strcpy is used to copy a pascal string to a local variable, what 
usually gets trashed is the return address.  Thus the program dies when
the routine tries to return to a bad address.  Now, some of you may be
thinking "Why not protect the stack?".  This isn't feasable because ...

1) The MMU's smallest page size is 256 bytes (on a 256 byte boundary).
2) Each entry in the page table uses 4 bytes (for 256 byte pages, 1 in
   every 64 bytes is used for the page table).
3) Even if you could do this, enabling/disabling protection after each
   routine would slow things down somewhat.

Protection is nice, no argument from me, it's just not as simple and not
the cure-all some people think it is.  True, it keeps programs from taking
the whole Mac with them, but this is useful only under Multifinder.  And
crashes on my Mac (that haven't been my fault) are very rare.

What would be nice is if Apple did virtual memory the correct way.  Rather
than use it to expand the memory space for Multifinder, it should be
used to have multiple virtual Macs, each with its own memory space.  But
there I go, second guessing the people who know much more about the
problem.

Additional info on the MMU and memory protection can be found in ...
"MC68030 Enhanced 32-Bit Microprocessor User's Manual" published by
Motorola.

Ray Fischer
rcfische@polyslo.calpoly.edu