[retroforth] Re: Further thoughts on blocks
- From: "Helmar Wodtke" <helmwo@xxxxxx>
- To: retroforth@xxxxxxxxxxxxx
- Date: Thu, 20 Jan 2005 21:16:38 +0100
retroforth@xxxxxxxxxxxxx schrieb am 20.01.05 20:00:59:
> Keep the code of rf clean.
It's a proposal for Reva. Also: what's clean? :) Writing a system for an "IBM
compatible PC" is a dirty task.
> Better use the current way of including
> blocks (or a 'load') and then a store of the current Forth environment.
> This means that the new binary file has all words already compiled. Thus
> a next start of rf is faster.
Could be. But a normal word takes about 5 bytes at least if it is compiled.
With the bytecode it needs exactly 1 byte. Numerical literals take 2 byes if
they are 0 ... 255.
> With the current available diskspace and
> memory the problem can't be that rf itself is 3000 or 5000 bytes.
Well. Could be. But it's possible to do processor and system related
optimizations to the code if you use a kind of bytecode. Also the bytecodes
that I was talking about are indices to an execution table - so no dictionary
search overhead is there while compiling the things: this is amazingly fast.
> store ( a a # -- ) | address of command to execute, new file name
>
> ' doit " rf.new" store
>
> Then rf.new will start running 'doit'. A zero address causes rf.new to
> start in normal mode.
Write it. It's not really that simple. It would also be possible to cause a
core dump and use this core dump as executable.
Bis dann,
Helmar
helmwo@xxxxxx
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/x-pkcs7-signature
-- File: smime.p7s
-- Desc: S/MIME Cryptographic Signature
Other related posts:
