🚀 go-pugleaf

In article <445369$o2n@orion.cybercom.net>,
Jerry Shekhel <jerry@cybercom.net> wrote:
>Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
>:
>: That's just the static code size. What about the total count of
>: executed instructions? I bet that goes up quite a bit more. Each
>: time you have to dereference a handle, you have to execute twice
>: as many instructions. Chasing dynamic links becomes slower.
>:
>
>Nope.  Your "twice as many instructions" comment is BS.  You lock,

Not my comment. Sorry.

>access as many times as you need, then unlock.  You don't have to lock
>or dereference twice for each access.

That may be true in some procedures. What about modules that get passed
only a handle in the function call?

>: >That says more about your skill as a programmer than it does about the
>: >Mac's memory scheme.
>:
>: Not every programmer wants to go through blockhead exercises that have
>: nothing to do with the computing task.
>:
>
>But they all have to.  It's called programming.  It's the "blockhead
>exercise" that programmers have to do so that others can perform their
>computing tasks.  LISP bigots will tell you that malloc() itself is a
>"blockhead exercise".  Compared to all the crap you have to learn to write a
>modern application, handles get lost in the noise.

Something that pervades much of your program can hardly get lost in the
noise.

>:
>: I wouldn't say that I am closed-minded person. Hell, I implemented the
>: crap myself, foolishly thinking that heap compaction would be neat!
>: After all, memory is a precious resource with which one must be
>: very frugal. Once you use it up, ain't none left!
>:
>: After I saw what my favourite list, B+tree and hash-table module turned
>: into when converted to use double indirection, I erased the project at
>: once!  I went to the library and pulled out Knuth, which at once set me
>: straight.
>:
>
>Perhaps you should have read the Knuth books *before* you wrote your
>heap compaction algorithm.  There is no need to do double indirection
>on every access.

Sure there is. How do you chase down a linked list without that, for
instance?  Or traverse a binary tree?  Of course once you obtain your
pointer to the data, you use it to refer to the data.  However, you have
to do the dereference while chasing dynamic links, and at each entry
point to a module that does something with your data structure.  The
pointers you pull out of the handles are lost when the activation record
of the processing module are disposed of.

Say I'm at the node of an n-ary tree, and I want to go to the third child.
I have a handle for it. I don't have a pointer. I could cache the pointer in
an auxiliary array, but this array would get invalidated during a compaction.
You have no choice but to follow the extra level of indirection. Of course,
once you have found that node, you can do with it whatever you wish without
going through the handle additional times. However, the pointer you thus
derived is a temporary variable that will be lost eventually. If the system
is pre-emptive (and even if it isn't), you also have to lock down that
handle, or your temporary pointers could become invalidated and your
code will bomb! In fact, if the system is pre-emptive, you are in danger
each time you have a temporary pointer derived from a handle that
isn't locked. This means that as you are chasing through a linked
list, you have to lock the handle of the "->next" reference, then from
the next node obtain the handle of the ->next->next node, unlock the
handle, lock the next one, etc... You can see why I had some _slight_
problems with heap compaction as part of a pre-emptive threading package.

I wonder how many Mac programs assume that the system is cooperative, and
don't bother locking handles when they "know" that they will have the CPU.
Hopefully, they will get to run in separate address spaces in Copeland! :)

This is why I mixed up the issue of coopeative multi-tasking and global
heap management in one post; you criticized me for doing so, but I felt
it was justified.  The two are not decoupled in the Mac operating system.
The heap management, in its current form, couldn't function under pre-emption.
I suppose that if each application is given a separate, virtualized Mac,
there won't be a problem.

If I had that 68K board with 512K RAM, and wanted to implement PMT OS
(this is a given), heap compaction would be out of the question, because
the discipline required in the applications would be atrocious, unless
each program just gave up and locked everything. In fact, I do have
such a board, and I will be writing some OS code on it.  It's not
actually a real board; rather it's a 68010 emulator of mine that takes
a kernel image in Sun 3 a.out format :) I've been looking for a home
for this project for a while; it requires the installation of all  the
GCC paraphernalia configured for Sun3 cross-compilation.
-- 
PGP key id is 0xD3C7995D.
Molybdenum 95! Got your ounce of fission byproduct yet?