LLL:Data types

[Mike Prince]

Let me preface the next few postings by clarifying my bias for a forth 
like LLL (though a loosely related one), and by the fact I'm writing a 
kernel that has already addressed many of these issues.

So...many of my comments will reflect the design decisions I have made 
regarding the software I'm writing.

I am not above rewriting ALL my code when our group decides on a better 
solution.  I just want to get the ball rolling.


On Sat, 17 Dec 1994, Dr. J. Van Sckalkwyk (external) wrote:
> 1. DEFINE "DATA TYPES"

My version goes like this; 8,16, and 32 bit signed integers.  A float, 
probably 64 bit.  We have length delimited short and long blocks.  A 
short block is up to 127 bytes, a long is 2^31 (remember signs). 

Our LLL code is forth like, so...

>     a. constants

Are of a type above inlined in the code, such as bytecode like
	PUSH16BIT 16bitdata
	PUSHLONGBLOCK 32bitlength data...data
You could also store data in a block and read it in.
	
>     b. variables

Either occur on the stack or stowed away in data blocks.  The stack is 
not type-centric.  More about that later.

>     c. numbers

What do you mean?

>     d. blocks

Are allocated by the kernel, and are referenced by a block 
handle:offset:datasize bytecode instruction, or a simpler blockhandle 
bytecode instruction.

>     e. pointers (to blocks)

We use integers.  See above for memory protection.

>     f. verbs

See instruction set.

>     g. interpretable combinations of a..f. ("friends")

Forth like.  Put data on stack, call operator.

>     h. objects

(I've changed some names)

CELL (basic unit of code+data)
	METHOD (code)
	DATA (one or more blocks of data)

The scope of the METHOD is only the CELLS DATA.  If you want someone 
elses data, you must ask them for it.

I'm kind of in a rush right now (guests are here), so please excuse me 
for not being more in depth.  I'll do that next post.

Mike