Memory model for the LLL

[Mike Prince]

On Thu, 8 Dec 1994, Francois-Rene Rideau wrote:
> What will be our memory model for the LLL ?

32 bit segments, each owned by a toolbox, or agent for resolving scope.

> For instance, will we allow pointer arithmetics ? (I hope not)

Yes, CPU's do it, why can't the LLL.  Remember, a HLL can always not use 
this feature!  Pointers are within segments for process protection.

> Will we allow infix pointers (not pointing to the beginning of an
> object) ?

If the LLL has to deal with objects as such, it might become too 
dependent on one way of "thinking", I'm going for a general memory 
allocation strategy and let the LLL program determine it's use of the 
storage (i.e. one "object" per memory allocation, an array of them, a 
stack of them, etc).

> What will be our integer and pointer size(s) ?

A departure I'd like to take it to FIX the sizes.  One aspect of Forth 
mentality is to use what you need.  There are operators which multiply 
and divide two 16 bit numbers, using a 32 intermediate.  This can GREATLY 
increase speed, while reducing storage.  How many other languages 
encourage the programmer to be such an artist and be frugal with what 
they have?  (Read not wasteful.)

> How will we adapt to different architectures ?

It will be give and take.  Nice answer, huh?

> Will 8-bit, 16-bit have to use 32-bit words anyway ?

No.

> Will 64-bit architectures have to throw away 32 bits out of 64 ?

Maybe, let's discuss this.  If I say add 16bit+16bit and it overflows, 
what happens?  On a 16 bit machine i've lost the info.  But a 32 bitter 
still has it.  Now do a little multiply and your two different 
implmentations have two different answers.  That's not acceptable.  I say 
a programmer defines a variable of size n, and it stays that size 
irregardless of the CPU native size.  That, in conjunction with the 
previously mentioned frugal programming practices will result in (I 
believe) predominant use of 16bit sizes.

> Will 20-bit architectures have to throw 8 bit out of 40 ?

20 is so odd in the first place (I assume your talking the MuP21).

> * Any implementation would use native pointers as values,
> with lower or higher bit(s) to indicate the value being pointer
> or integer, thus losing one bit. For ;ore portability, integers
> would come with size 8, 16, 32, or 64, even though the architecture
> be 20 bit.

I thought about this before, but it sounds like a huge performance hit 
for the LLL.

> * Pointers would never be infix (except in transient state);

Transient state?  You mean migration or message passing?

> * GC would happen only during cooperative multithreading, while
> preemptive multithreading is allowed for real-time behavior on
> preallocated (outside global GC) zones.

GC would happen when the kernel/memory manager object says it would 
happen.  It is not dependent on the state of any threading.

> * objects with size different than pointer size are allocated on
> heap.

All memory is allocated from the heap.

> * object type is determined by which page it is located on and/or
> which tag precedes it.

An object can be tagged by the first few bytes of it's memory 
allocation.  That way "higher-level" objects would be defined by the HLL 
under which they were created.  Remember there are going to be a lot of 
low-level things which cannot be objects which will be manipulated by the 
LLL (although you could build a container class, but that in itself would 
be a hack).

> * low-level operators like addition are explicitly typed, and won't
> have to test object type.

Completely in agreement.  But note that this goes in contradicition to 
the pure object model.  I'm get the feeling of a compromise?


Mike