LLL stack questions

[Raul Deluth Miller]

Mike Prince:
   I'm hoping cells code will typically be under a few K.  Data might 
   baloon, but by factoring we could control it.  The nice thing is 
   evolution.  Programming styles that work would be used (i.e. SoftCo 
   writes well factored code and breaks data into reasonable sizes managed 
   by cells, their software runs fast, MicroPros write huge apps that are 
   memory hungry, their software crawls along.  Who'll stay in business 
   longer?)  I hope I'm not missing the point on some problems which must 
   have large pieces and CANNOT be factored, am I? 

The critical issue here is automatically generated code.  If we don't
provide a decent mechanism for porting existing softwar, we'll never
get off the ground.  That means we need to do something decent for a C
compiler, and we need to deal with automatically generated C code
(which is the way a lot of compilers and tools are implemented
nowadays).

Currently, I'm thinking of treating the "cell stack" as a register
set, and providing the illusion of a flat adress space using some sort
of "annotated pointer" (which denotes the memory array as well as a
virtual offset) -- I don't know if we can do better than this for
arbitrarily large data objects without hurting performance for smaller
objects or objects of "known size".

Remember, Ccode frequently manipulates pointers to "anonymous data" orr
"anonymous code".

I'm not sure how to treat arbitrarily large code objects (e.g. PERL's
yacc parser).

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