Memory model for the LLL

[Chris Harris]

On Thu, 8 Dec 1994, Francois-Rene Rideau wrote:

> What will be our memory model for the LLL ?
> For instance, will we allow pointer arithmetics ? (I hope not)

No; evil!  =)

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

Care to explain for those of us non-pointer-masters?

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

Well, it would seem desirable to have it relate to the underlying 
hardware.  This might create inconsistancies, though.  How about we have 
a minimum size for each, but anything bigger is ok?

> How will we adapt to different architectures ?
> Will 8-bit, 16-bit have to use 32-bit words anyway ?

If the LLL compiler wishes, sure, but otherwise, no.  On the x86 arch., I 
see no good reason to do this.  I suppose it is a pain to have different 
data sizes, but if they can do it in C/asm, so can we!  =)

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

No; if it'll be faster/easier, they can use the extra 64 bits.  (See above.)

> Implementation ideas:
> * 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.

Could I ask why we are differentiating between pointers and integers?  If 
we're doing this, why not make floating point types, and maybe a bunch of 
others?  Isn't this complicating the issue?

Also, how/why is this 20 bit?  Sounds like a strange choice....

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

huh?

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

Repeat after me, "Cooperative multitasking is evil.  Cooperative 
multitasking is evil...."  =)  Seriously, though, cooperative 
multitasking really kills my new reliability goal.  Agents should not be 
allowed to eat the whole CPU.

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

Type?  Tag?  Care to explain why we have to have a type system, and what 
types would be involved?  I feel the extendability goal perhaps getting 
treaded on?

-Chris