🚀 go-pugleaf

In article <43uq94INNpbl@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
|> In article <rbarris-2109951707350001@192.168.1.16>,
|> Rob Barris <rbarris@quicksilver.com> wrote:

[ Programming with Handles on the Macintosh... Text from Rob Barris
further below ]

Kazimir Kylheku:
|> Right, that's obvious, because your properly written program always
|> takes care to dereference through the handle.

Unless you lock it.  After you lock a handle, the object won't move.

Rob Barris:
|> >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.

Remember the original Macintosh had 128K of RAM, and 22K of that was
the screen buffer.  And the 68000 has no MMU, and some instructions
that can't be restarted.

[ realloc comment trimmed... ]

|> There is another way; it's called a segmented-paged MMU like the
|> 386.  

Except the 80386 and 68020 are about two and a half years after the
introduction of the Macintosh.

|> When you allocate an object, you can reference it through a
|> segment:offset address. 

Segmented memory spaces rarely solve real problems.

|> >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.

|> With a segmented MMU, I could stick the objects into different segments.
|> This is messy, because the compiler has to be segment aware, and I may
|> want many more objects that the segmentation unit allows.

That's usually the problem; running out of segments.  Or having
objects too big to fit in a segment.

[ trimmed ]

|> In any case, I never advocated that a hardware solution using an
|> MMU is superior to using handles (though some other contributor to
|> the thread did make that claim).  I was thinking purely of a machine
|> without an MMU the entire time. In fact a 68K board with about 512K
|> RAM or even less was what I precisely had in mind.

|> Douglas Comer's Xinu operating system originated on a DEC LSI-11
|> microcomputer which could address 64K of RAM. It's preemptive and
|> _doesn't_ use handles for memory allocation, nor did early versions
|> feature any kind of virtual memory.  

Sure, it has virtual memory, and probably had 512 byte or 1K pages.
Programs were smaller back then; partly because the user interface was
line editing, or if you were lucky, an 80x24 full-screen interface.
The display page is 1920 bytes.

Chris
-- 
Speaking only for myself, of course.
Chris Wood    christw@lexis-nexis.com   ChrisCWood@aol.com