[retroforth] Re: Source compression, Bytecode and faster startup for huger apps.
- From: Charles Childers <crc@xxxxxxxxxxxxxx>
- To: retroforth@xxxxxxxxxxxxx
- Date: Sun, 17 Oct 2004 14:50:42 -0400
> How can bytecode help with optimizations? Of course it could be
> a representation an optimizers uses to make more optimal code from.
> But I would think that it's better to use some more powerful
> structures as input for an optimizer - eg. lists that are only
> temporary created for the optimizer.
I was considering writing an optomizing compiler that used bytecode as a
temporary structure. It'd compile words to bytecode, look at that,
optomize it, and then do the real compilation. It's probably an overly
complex approach though.
> Bytes are not differently encoded on most platforms. I dont have
> a unit of input that's huger than a byte or a range of bytes.
Interesting. It's still an issue I'd watch though... If you have a
system that only supports 32-bit loads/stores, you'd still be affected.
(kc5tja's kestrel cpu design was like this iirc)
> I'll soon release a source. I've now a first version running that
> does in core what I want.
Cool!
> My first messurements say that an implementation like RF now takes
> at least 50% of startup time for a huger application with playing
> the word sequence "32 parse find". As more words as the application
> defines the more worse it will be, because words like "DUP" have a
> very bad position in dictionary but will be frequently used.
Some things could be changed. Instead of looking up the actual name, a
hash could be used for instance. That would be faster, but harder to
follow. I *might* use hashes in TetraForth though.
An eventual goal for TetraForth is to allow you to 'save' the current
state to disk, and have it intact when you reload later on. That would
basically be the core of turnkey support as well.
--
Charles
Other related posts:
