CORE CODE!

[Raul Deluth Miller]

   1. Symbolic assembler (J) conventions

A language named J already exists.
ftp://archive.uwaterloo.ca:languages/apl/j

   The core code assumes that the following exist: 2 General purpose
   registers AA, BB 3 Pointer registers pp, qq and rr that point to
   three blocks of memory (already set up) termed MEMpp, MEMqq and
   MEMrr

       MEMpp contains "program" to be interpreted
       MEMqq contains "meanings" of each item
       MEMrr is a table of addresses of "primitive interpreters"

I'd be interested in knowing why you factor out "meaning," I couldn't
get the concept of any of these memory regions from your post.

   A stack, called yY.

Moreover, I'd tend to prefer an independent stack for each primitive
data type, and in addition to basic instructions (dup, add, ...) for
each stack, you need a complete set of movement instructions (e.g.
copy from integer stack to fp stack, copy from program stream to
character stack (do we want to bother with chracter stack?)), as well
as a set of instructions for manipulating arbitrary data structures
which mix data types (e.g. "memory").

Um.. I think that it's a virtue to minimize data movement.  However, I
expect (hope) that rather than use the "bank of registers" which wind
up having complicated multi-level cache designs, it will be
conceptually simpler to build a set of well-designed stack
manipulation instructions.  Register stuffing is a packing problem.
As much as possible, I'd want to provide simplistic underlying models
to avoid a lot of initial work on packing problems.

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