Re: If you got to choose the syntax, what would you do?

Dennis Ruffer wrote:
You can execute the stream serially, but there has to be some local
storage to hold the largest loop sequence. I haven't seen this done
much, due to the speed issue. However, if storage is a priority, it
can be accomplished with a limit on the size of loops.

We can execute a stream serially by jumping to or calling an incoming
port. The tokens interpreted are just opcodes. The concept of looping
can only apply when the looping address remains the same, in a
stream all execution takes place at one address unless it makes
calls to code outside of the stream. So one word loops, micro-next
loops can be used in the class of streamable programs.

However, in both cases, we did de-tokenize to gain run-time speed.

Using software to receive and detokenize a stream takes time and
memory so we use hardware.

This assumes you have enough storage to decompress/detokenize.

Sure. On a SEAForth24A with 64 words of memory the idea that a
single node has enough memory for a layer of software that deserializes
an incoming stream and detokenizes it and then executes it is not
a foreign one. We do that too. But between on-chip neighbors
we have hardware that is ten million to ten billions times faster than
that.

You trade off stream size with local storage and run-time speed.

Indeed. We used compressed tokens to reduce the stream size,
increase the speed, and reduce local memory storage to one word
in the case of the example given.

It also
assumes that the message is going to be executed more than once.

If we are going to execute it more than once then we have to use the
download and collect it in memory to call it more than once. But we
have a faster mechanism for remote proceedure calls, remote execution
which is stream execution.

If you messages are small, as in this demo, there's not much to gain by
doing more elaborate compression.

We comile the demo I gave to one 18-bit word and send it and begin
execution in a couple of nanoseconds with a neighbor and at a cost
of a few more ns per hop with arbitrarily routed messages. The
compression of message size and hardware execution of the messages
is important for that sort of speed..

There have been some guesses in this newsgroup and posts about
Forthlets being about the kind of tokenization and compilation that
you describe, but they aren't. But I do appreciate your educational
explanation of this stuff.

I'm not sure I see the difference. SEAforth simply executes the tokens
directly, or am I missing something?

Four different things have been suggested.

sending Forth as tokenized native code compiled with an optimzinig
compiler

sending Forth as tokenized code that requires detokenization in
software to run

sending Forth as source and compiling it at the target end then
executing it

sending Forth as tokenized source code that gets detokenized in
software
then compiled, then executed

Remember that in a tokenized concept, the detokenization step is only a
part of the normal compiler. The interpreter step is reduced to a
table lookup.

And remember that smallest and fastest of the four items is the first
because the table lookup is done in hardware and takes a small
fraction of a nanosecond.

Moving beyond the message as command concept requires that you have a
module store. Then your tokens can reference those modules and you've
just scaled up one level. However, you have to architect a storage
solution to get there.

Forthlets move from the encapsulation of code as data and data as code
in data streams to the next level of scale with 'module store' so that
a programmer can refer to programs and data structures by name and
have them treated as code or data by other programs using simple
syntax.

While the tokenization approaches can be considered to simply be a
source conversion technique, I do think they are significantly
different to be called an alternative to source, and there is enough
history and prior art to indicate a significant preference.

I am willing to make a distinction between tokenized source and
'normal'
ascii text source. colorforth and aha are based on the concept of
tokenized source. They don't use ascii source, but they use source.

I also think there is a distinction between tokenized executable code
and
native code. Unless the 'tokens' in the source and the 'opcode tokens'
are very close or the same thing it is just normal native code.

What are you looking for to give you this sense?

I have been looking for the syntax people say that they use to specify
a program
and to specify that that program is to be remotely executed by another
computer
and to make that remote execution happen.

I have heard of several methods now involving source, tokenized source,
compiled execution tokens requiring decompression and compiled native
code.
And with these different methods people don't all use the same syntax
to specify
these different things.

Thanks for the explanations.

.

Relevant Pages

  • ssh2 mod and exec function
    ... read the stream answer after execution in the remote computer. ... reading success and the following ones fail. ... the same process only the first exec could be read. ...
    (comp.lang.php)
  • Re: Processes and Threads
    ... A thread is just a stream of execution. ... Call a function like 'fork' that creates a new process that starts ... with a single thread. ...
    (comp.os.linux.development.system)
  • Re: exec() and sending to STDIO and reading from STDIO
    ... *now use your buffered stream and read from the process using the ... Yes my suggestion was for a code which will end quick enough. ... Incase you want the process to finish its execution within a ... time limit, you could always spawn a thread which will count the time ...
    (comp.lang.java.programmer)
  • Re: Strange behavior when closing stream
    ... I don't know too much about the details of your stream -- they tend to ... block around your reader. ... is for the method to complete execution. ... the side effect of keeping the output file "locked" until I exit the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Obstacles for Tcl/Tk commercial application development ?
    ... this is no problem: the compiler will refuse to ... previous message, it is impossible to check all execution paths, ... kilometers, which is clearly a type error. ...
    (comp.lang.tcl)