[retroforth] Re: Source compression, Bytecode and faster startup for huger apps.
- From: Charles Childers <crc@xxxxxxxxxxxxxx>
- To: retroforth@xxxxxxxxxxxxx
- Date: Sun, 17 Oct 2004 05:49:22 -0400
> Charles, you made a comment there and now I'm interested to know,
> if you are have some plans to support things like Bytecode with
> RetroForth (not in core but in extension).
Bytecode fascinates me, but I don't think it's as useful as people
claim. The problem is that 99% of all bytecode interpreters rely heavily
on external functionality. If you don't provide that, they won't work as
well.
On the other hand, I do see how bytecode can be useful for certain
tasks. As I mentioned in my comment on the ForthFreak wiki, it would be
helpful for compilers. Optomizations could be done much easier in my view.
I do plan to do some work with bytecode in RetroForth though. Since I'm
planning to write versions of RetroForth for other CPU's, it will be
useful there. And it'll provide a way to work around x86-specific
features. It won't be part of the core though, and official releases
will use STC threading if at all possible.
> I've an idea on how to implement a very simple kind of bytecode that
> is absolutely portable between FORTH systems since it does not define
> any semantics to a special encoding. Here is my idea:
How do you work around endian issues and primitives? RetroForth uses
several non-standard primitives (the multiple if words, loops, etc)
which most other Forths don't have or support cleanly at this point. And
the endian differences between x86 and PPC would also throw some things
off a bit.
Your bytecode approach looks interesting, and I'll have to study it
better when I'm not so tired.
> One problem with RetroForth I see at the moment is the two-dictionary
> design, that makes optimization of the dictionary searches a little more
> complicated than they would have to be - so for each bytecode possibly
> two entries in the different dictionaries could match. A way out of this
> (but reducing compilation speed) would be to only honour the forth
> dictionary.
The macro dictionary is primarily used inside the compiler. You still
have the problem with other Forths, where you deal with IMMEDIATE words.
I just place them in a separate dictionary which allows cleaner source
organization and simpler headers.
This won't be a major problem for me, at least at first since I'll be
generating bytecode on an x86 and running it on other platforms.
Eventually though, most RetroForth programs will run on any other OS
with minimal changes. (Think things like cell size or endian issues for
example)
> So far I've written an encoder in Perl and a decoder in x86 assembly.
> Now I'm on the big way to make it running inside an interpret-loop to
> do the dictionary-search optimizations.
Excellent. I look forward to learning more of your efforts, and I'll
keep you all posted on mine as they begin to take form over the next few
months.
--
Charles
Other related posts:
