Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.forth
Subject: Re: blocks and overlays question
Date: Tue, 27 Sep 2016 13:25:29 -0700
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <87a8et5buu.fsf@jester.gateway.pace.com>
References: <87inth5hk5.fsf@jester.gateway.pace.com> <de32ef92-68f6-42d9-9e9f-0530ad4fb881@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="2aed369a7b4699bde3e169ff4d831123"; logging-data="22643"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/eIWNWMxSJdzVf9ZIOTWFD"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:P53TGf1kePB9nvk8/tKSLcGBuZA= sha1:FIJuv+wVCa0Qni3s9W1uAeIsj38=
Xref: csiph.com comp.lang.forth:51402

foxaudioresearch@gmail.com writes:
> On my old DOS HSF/Forth system, BLOCKS is a library you pull in.  The
> source code for just the blocks and buffers system is 154 lines of
> code.  It compiles to 1512 bytes without the names. It allows the
> system to compile source code from blocks or files by vectoring the
> appropriate words.

Cool, thanks.  But I'm realizing that loading blocks consumes ram and if
it doesn't get released, it's better to compile the libraries into flash
and run them from there.  

> My old TI-Forth system had floppy drives with only 90K byte per
> disk. It worked great but slowly due to Fig-Forth and memory
> wait-states on that !@#$! machine.

Heh, I've always wondered what those environments were like.  I've never
tried booting Fig-Forth but F83 ran right away under a dos emulator.
http://www.angelfire.com/in/zydenbos/WhatisForth.html claims:

   a self-contained interactive Forth system including an editor,
   assembler, and even multitasking support can easily be put in an 8 KB
   EPROM.

I guess that meant Fig-Forth but even still, it's surprisingly small.

> However some clever linking and unlinking of the dictionary
> should have made a binary overlay to specific buffer possible.

Cool, but I guess overlays are more trouble than they're worth in the
imagined environment.  Being able to compile code to flash and run it
from there probably makes up for it.