Denesting
bobja...@juno.com
> 2 of 2
>Date: Sat 16 Jul 2005 03:09
>From: Charles Hoffman
>ward mcfarland wrote:
>> bobja...@juno.com <bobja...@juno.com> wrote:
>>>One obvious way to do this and cut down the call/return
>>>overhead is expand words with code reproduced
>>>in-line within higher level words.
bj: I have taken Jerry's advice and done a few
tests. I find that inlining code rather than
calling it saves a significant amount of time.
>> Shades of
>> <http://en.wikipedia.org/wiki/Bytecode>
>> A tokenized Forth would be interesting for this. Platform independent
>> tokens, platform-specific expansion and we could go head-to-head with
>> Java ;-)
bj: I understand anything about tokenized Forth.
How is this implemented. What source would you suggest
to learn about it? But how could inline expansion
at execution time be implemented?
>ooh ooh... and a JIT compiler that would dynamically compile words into
>native code that are seeing frequent use... i'm kind of liking this idea ;-)
bj: "Dynamically compile"? It wouldn't be platform
independent anymore, so how would that work?
Bob Jaffray
Jeff Fox
> bj: I understand anything about tokenized Forth.
> How is this implemented. What source would you suggest
> to learn about it? But how could inline expansion
> at execution time be implemented?
A simple example of a token threaded Forth could be
implemented using 8-bit tokens as indexes into a table
of addresses of callable code, or addresses
of inlinable code or whatever. So you would have bytecodes
that refer to routines through a table. An escape code could
give you access to more than 256 etc.
Everything above the token level can be portable. The
tokens could be interpreted as a table lookup to a callable
routine but's that not the only type of tokens one could use
in an implementation.
The tokens could also be native code if implemented as the
native code of a processor. Then one mostly just strings
them together although some optimization is possible and as
inlined code so they can't be expanded at execution time.
The Sh-Boom, Ignite, and later MISC processors are examples
of a sort of tokenized Forth as native code. The underlying
Forth model in Mr. Moore's colorforth looks like a subroutine
threaded Forth with inlining of the most frequently used Forth
words as inlined native code. What could be tokens at
compile time used with a look up table at runtime are expaned
at compile time into inlined native code. But called words
don't get denested either at compile time or runtime. But
could compile portable tokens and then on some systems
denest then as just in time compiling and running or you
could have a coprocessor that denests higher level nested
code.
In sequential processors the fact that memory is so much slower
than processors does suggest the idea that reading instructions and
expanding them inside of the processor might speed things up.
But it might be a very expensive proposition in hardware unless
you find some clever ways to expanding code one the fly.
At iTV we used self-expanding boot code, but boot code
running out of Flash into DRAM is slow and bandwidth limited.
Having it expand when it gets to faster memory makes sense
if loading it from slow memory is the bottleneck.
But the princple of loading compressed code and decompressing
it was there. On multiprocessors where code and data are
moving around on some kind of network compressed formats do have
an advantage sometimes.
But a token threaded Forth with a software token interpreter
could alternately compile the tokens to the inlined code that
would be similar to the native code normally referenced by
the tokens.
Open firmware is an example of system where portable drivers
for hardware can be written and run on machines with different
hardware. Firmware can be organized as tokens so that the
details of the underlying processor are smoothed over and
portable firmware drivers can be written.
> bj: "Dynamically compile"? It wouldn't be platform
> independent anymore, so how would that work?
Dynaically compile the portable tokens into platform
specific native code, JIT, Just in Time compile. In that
case the tokens can be executable code with an interpreter
or treated much like source tokens with a just in time
compiler.
If one can load source and dynamically compile optimized native
code faster than one can just load the pre-expanded optimized
native code then I see an advantage to doing it. I haven't
seen very many other people using the technique. If you
come up with a new and better way to do it then good for you
but it isn't of interest to most people doing Forth.
I also think many people have the impression that you want to
optimize something that they optimized in a different and
better way long ago. So denesting on the fly is pretty low
on most people's lists.
Best Wishes