Re: More SEAForth questions

> Hi Jeff,
> 1. In the crawler code @p+ is used in the left hand column as the
> runtime part of a magenta variable,

Well magenta is colorforth, and variables put an address on the
stack, while values and literals put the contents of an address
on the stack.  So I would say that literals have more in common
with values than with variables.

> and in the right hand part ( run on the neighbour node )

You are describing the use of two columns for source code
where the left column is executed opcodes and right column are
data statements loaded as data, as literals by the code that
is executed on a node.

Those data statements are then sent to a port, not necessarily
for execution on the immediate neighbor sharing that port,
and are executed by another node.  So the column on the right
is data statements to one processor and code statements to another.

> as a port fetch.

Yes.

> Is this a typo,

No.

> are they different colours, or is there some other
> explanation?

Perhaps you are talking about a web page where color was
used for emphasis?  Color is not used in t18.  Columns
are not used in colorforth.

I introduced columns to t18 and have done presentations on
it and written a thread about it in c.l.f.   I don't know
exactly what they put on the web site about it yet.

Columns used as parallel syntax was my idea it was an
evolution of simple syntax.  We had several threads about
it in c.l.f where I asked people what syntax they would
prefer to use to specify that one sequence of Forth code
was to be compiled as data statements and sent to
a different computer for remote execution but about
all got as an answer was 'Forth syntax' ;-)

This meant that they would put a Forth compiler on the
target side, use some tools to transmit the program source,
compile the application on the target node, then store the
result, then jump into the compiled code.  And yes
that would be one level of granularity for remote execution
of some Forth code.

But we were looking for way to do it with one statement,
nothing special, little syntax, in a couple of words of
code and a few nanoseconds total.  I think most people
in c.l.f didn't have any preference on what simple
syntax they would prefer to do something like that.  But
I did ask. ;-)

I explained what we did to solve the problem of specifying
a sequence of source code that should be compiled by the
compiler but not treated as executable code on that node
but instead put inside of a wrapper so that it could be
sent to another processor for remote execution was to
just compile the code as part of literal data statement.

some other things we did:

people compiled " dup dup dup dup" then decompiled the code
and wrote down the magic number.  now they could load this
in source code but when you see 2c9b2
do you think " dup dup dup dup" ?

Pretty clearly syntax with magic numbers is not very clear
and not easy to write or read even with lots of comments.

" dup dup dup dup" compile-token-to-t route-token-for-remote-
execution etc.

worked and looked like most other people's style syntax but
we thought it could be simpler

" dup dup dup dup" remote-execute

or perhaps

rx . .            dup dup dup dup

seemed a lot simpler and to be more explicit we wrote

@p+ !a . .        dup dup dup dup

which in this case is only executing two non-nop
opcodes.  the nop opcodes can be replaced with useful
opcodes in real code.  But they are there in this
form to align the " dup dup dup dup" so that it is
compiled into one word and in this case the literal
field of a literal.

In the last case your eye and mind can see in two columns
all the code on one node including the literal data loaded
as literals into T and expressed as compilable source code
but not compiled for execution on that node.

and your eye and mind can focus on the right column only
and you see exactly the code that is executed in the port
on some other node, or send to it as data depending on
whether it is reading its port as data or executing it
when the data arrives at the end port destination.

And since routing is decoupled from remote execution
it works the same way whether you are want to remote
excute directly on a neighbor's port or if there
is an open route and it is going to a more remote
location for execution.

the other question:

2. R D L U are just the names of ports specifying a route.
Processors are arranged in a simple 2D x y grid.  Better
not to tell people to picture mapping to 3D sphereical
universes or to invert anything.