LLL stack questions

[Raul Deluth Miller]

   Elements on the stack only occupy as much space as needed (chars
   get 8 bits, floats 64, etc) I think it will be marginally harder to
   implement.  Harder to program for at the low-level, but most of the
   time we'll be buffered by a medium or high-level language, and to
   them it doesn't matter.  I do think it would be more powerful.

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?]

	LD.8 	'A'
	LD.32	*ptr
	LD.64	3.141596
	SWAP.32<->64

or did I get that backwards?

Perhaps there's a rule that unaligned accesses may be very slow on
some machines (then just write an unaligned address interpreter which
hangs off the unaligned address trap vector).

Which reminds me: I occasionally hear gripes from people designing
floating point algorithms that there's no easy way to cast an integer
to a float.  Apparently, there's lots of table lookup optimizations
that become dreadfully slow when you need to write your (integer)
index out to main memory to cast it to float.  Main memory is
acquiring many of the properties secondary storage had about 20 years
ago.

-- 
Raul D. Miller          N=:((*/pq)&|)@                 NB. public e, y, n=:*/pq
<rockwell@nova.umd.edu> P=:*N/@:#               NB. */-.,e e.&factors t=:*/<:pq
                        1=t|e*d    NB. (,-:<:)pq is four large primes, e medium
x-:d P,:y=:e P,:x                  NB. (d P,:y)-:D P*:N^:(i.#D)y [. D=:|.@#.d