Re: Images and libraries

Bruce McFarling <agila61@[EMAIL PROTECTED]
> wrote:
> On Mar 28, 4:48 pm, an...@[EMAIL PROTECTED]
 (Anton Ertl)
> wrote:

>> In any case, there is no reason to make the Memory Allocation wordset
>> a second-class citizen for programs.

> Dynamically allocated memory is ... uhm, dynamically allocated?

> I don't see how its unusual for statically allocated memory to be
> loaded from an image and dynamically allocated memory to be created
> by an initialization process.

> I would, indeed, be surprised if the existing practice that was
> standardized in ALLOCATE provided any such entitlement to sup****t
> libraries for applications that the memory allocation wordset would
> infer which allocated memory would managed by the initializing
> routine when starting a system image and which allocated memory
> would require auto-initialization.

> However, what I expect from a SAVESYSTEM is to get my codespace and
> ALLOTted dataspace back as it was when SAVESYSTEM executed, and to
> have a hook into the initialization routine that runs when the image
> is reloaded.

That sounds right to me too.  When calling an OS to get memory you
sometimes have no way to control where that memory is.  In UNIX you
might be able to cope by allocating all memory via sbrk(), so all
dynamic meory is contiguous.  In general, however, a requirement that
SAVESYSTEM save all dynamic memory places a great burden on the way
that ALLOCATE is implemented.

Andrew.