Aleksandar Donev wrote:
...
> Another goal however would be to have a rellocatable data-structure,
> that is, one whose storage can be moved without having to redo the
> internals, like changing next pointers. Obviously if one uses pointers
> like I say above this won't work.
This part of what you're talking about I've been working
at as part of my preprocessed language. I tend to mimic the
way virtual memory hardware works. The data (regardless
of it's actual size) is allocated in chunks (usually some multiple
of the size of a NODE). If you need more space, a disjoint
chunk is allocated separately, but the the indices into the
structure are interpreted to make the whole structure look
contiguous to the user program. This adds one extra level of
indirection to the references, so it won't be as fast as other
methods. But if lots of nodes are build and/or deleted, the
extra indirection would be cheaper than memory management
calls to allocated/deallocate on a node-at-a-time basis.
I don't know how you would do this directly in Fortran without
exposing the extra level of indirection to view. On the other
hand, if operating systems allowed direct manipulation of the
virtual memory hardware (at least, at the application library
level) then the cost and visibility of the extra level of indirection
would disappear since *all* memory would still use the hardware
page translation mechanisms.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
|