🚀 go-pugleaf

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

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

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

I wouldn't do that at all. If a program requires that the size of an allocated
unit change, I would have it go through a function that's similar to the
standard C realloc().


By the way, the MMU method you are thinking of doesn't, by chance, involve
leaving large gaps in the address space between objects so that you can
grow them without changing the address?

There is another way; it's called a segmented-paged MMU like the 386.
When you allocate an object, you can reference it through a segment:offset
address. If you need to move the object, you just move it somewhere else
in the virtual address space, and change the base address stored in the
segment descriptor table.  Mind you, the lame 386 implementation gives
you a very narrow limit on how many segment descriptors you can have...

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

I suspect that the solution you are after is to allocate all objects on
a page boundary, with lots of empty virtual space between allocations
where frames can be added.  That's costly not just in terms of address
space, but also because of the cost of using at least one full frame for
each allocation, no matter how small.

I wouldn't do either of these things, needless to say. I do use the technique
of inserting dummy pages between allocated data in order to use the hardware
to detect instructions that would normally corrupt the heap but only for
debugging purposes.

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.  (I suspect that Xinu/386 might).

-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.
Microsoft users: crash test dummies?