LLL stack questions

Mike Prince mprince@crl.com
Tue, 20 Dec 1994 13:26:59 -0800 (PST)


On Tue, 20 Dec 1994, Raul Deluth Miller wrote:

> I don't know about "more powerful," but this would definitely be
> slower on a RISC system.  [Well.... "more powerful" usually equates
> to "slower" so maybe you're onto something here?]

I should have qualified my "more powerful".  Hopefully using less memory 
for code and a data due to instructions and data doing "just" what they 
need to do, will result in effectively more code and data in the cache 
and CPU pipeline.  It will hopefully reduce total system memory demands 
which will minimize again, how much we'd have to swap out to disk, and 
how much bandwidth we'd need during transmissions.

This is a _completely_ untested theory.  But it's worth trying out.  As I 
said in another post, it is not much work to change between a pure 32 and 
a multi-type stack.  I'm also not a firm advocate of either so don't 
expect to see my feelings hurt about any decisions. 

As far as you comments about RISC, you're absolutely right.  Unaligned 
words would give RISCish machines (actually many) a real big headache.  One 
(not very good solution) is to write code using a subset of the language
(only 32 bit operations).  Then you'd kindof have the best of both worlds.  I 
really think the overhead of supporting other data types on the stack 
will be minimal (a few extra K of kernel code).

> 	LD.8 	'A'
> 	LD.32	*ptr
> 	LD.64	3.141596
> 	SWAP.32<->64
> 
> or did I get that backwards?

How about
	LD.8 'B'
	LD.32 *ptr
	LD.64	3.141596

	LD.32 -12	; offset of start of data
	LD.32 4		; size of data
	PULL		; move to top of stack

This is just one idea I have, some "higher level" operators.  For 
instance PULL would take data from inside the stack and move it to the 
top, shoving everything else down.  It takes two arguments in LLL code.  
A simple optimization during compilation would realize the stack 
arguments are constant and substitute the native primitive.  I know some 
won't like this, so I'm also up for the SWAP.type<->type.  I was playing 
with KISS techniques though.

What do you think?

Mike