🚀 go-pugleaf

In article <43qddkINNpti@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
(Kazimir Kylheku) wrote:
> I suspect that in the long run it would be easier to fix an application's
> allocation pattern, should the need arise, than to force yourself to
> complicate _every_ application with nonsense like memory handles and
> double dereferencing.
> 
> I think the original Mac designers should have stuck to pixel pushing,
> and hired outside help to do the internals. I suspect that the 
> NIH (Not Invented Here) syndrome had a lot to do with it.

I suspect the cost of RAM, and lack of an MMU for the 68000 might have had
some influence as well. Recall that an app in those days had 75K of free
RAM or so to play with on a 128K machine.

The Mac's predecessor, the Lisa had a sort-of MMU - Apple worked around
the inability of the original 68000 chip to do true VM (not all
instructions were restartable!) by teaching the compilers not to use "bad"
instructions, and using some external logic for an MMU mechanism. Not a
solution with long legs.

One of the key benefits of handles is the way with which they can be used
to represent structures of varying size (that is they can grow and shrink-
and none of the many references to such an item in data structures, the
stack, local variables become invalid when that happens). And you can ask
the system how big one is.

I can think of a way to do that without actual double indirection, but it
chews up an awful lot of address space and requires an MMU. Perhaps you
could suggest a better way? You are given a Motorola 68000 motherboard and
512K of RAM. Go.

For extra credit, describe how you would go about representing objects of
variable-length on a system that does have an MMU. References to said
objects are not allowed to become invalid at any time until the object is
disposed.

Rob Barris
Quicksilver Software Inc.
rbarris@quicksilver.com
* Opinions expressed not necessarily those of my employer *