Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #51404

Re: blocks and overlays question

Show all headers | View raw

"Elizabeth D. Rather" <erather@forth.com> writes:
> The common program would end with an empty definition such as:
> 	: OVERLAY ;
> ...and each of the extensions' first block would begin with:
> 	FORGET OVERLAY : OVERLAY ;

Hmm ok, that's really simple and could be used for multiple levels of
overlay.  FORGET simply rewinds the dictionary to a specific address.
But what happens if the common program extends the dictionary while the
overlay is loaded?

> Blocks have been used for source (as described above) as well as data
> storage. I am not aware of blocks ever being used for pre-compiled
> code, which is what you seem to be implying.

Yes, that's what I was imagining, to avoid using ram for the compiled
code.  But with the ability to reclaim the ram using overlays, compiling
from source sounds more attractive.

>>> There are lots of small Forth's to take as an example CamelForth,
>>> noforth etc.  No need to go back to the pre-ANSI F83.
>> Oh, I didn't realize these had blocks and utilities.
> Yes, there's an optional Blocks wordset. 

I meant I didn't realize CamelForth and Noforth (two specific
implementations) supplied blocks.  I haven't checked Noforth but I don't
see anything about blocks on the Camelforth site.

> Well, you have to figure out how much mass storage you need for source
> as well as data.

Yes, my idea was to split the 64k flash as 32k for the system and 32k
for the user.  Maybe the user part could be smaller, unless a larger cpu
or external flash is used.  The system could also use up to half the ram
(i.e. up to 10k) which sounds plentiful for a dictionary extension, a
few block buffers, etc.  The user would get the other 10k.  The base
system and dictionary might have to run directly from flash to save ram,
though running everything from ram would be more traditional.

How many block buffers did a usable block system actually need, assuming
the underlying storage was quite fast?

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

blocks and overlays question Paul Rubin <no.email@nospam.invalid> - 2016-09-27 11:22 -0700
  Re: blocks and overlays question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 20:51 +0200
    Re: blocks and overlays question Paul Rubin <no.email@nospam.invalid> - 2016-09-27 12:36 -0700
      Re: blocks and overlays question "Elizabeth D. Rather" <erather@forth.com> - 2016-09-27 10:16 -1000
        Re: blocks and overlays question Paul Rubin <no.email@nospam.invalid> - 2016-09-27 13:41 -0700
          Re: blocks and overlays question "Elizabeth D. Rather" <erather@forth.com> - 2016-09-27 11:36 -1000
            Re: blocks and overlays question Paul Rubin <no.email@nospam.invalid> - 2016-09-27 15:36 -0700
              Re: blocks and overlays question "Elizabeth D. Rather" <erather@forth.com> - 2016-09-27 13:33 -1000
                Re: blocks and overlays question Paul Rubin <no.email@nospam.invalid> - 2016-09-27 16:54 -0700
          Re: blocks and overlays question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-28 09:44 +0200
  Re: blocks and overlays question hughaguilar96@gmail.com - 2016-09-27 12:22 -0700
  Re: blocks and overlays question foxaudioresearch@gmail.com - 2016-09-27 12:51 -0700
    Re: blocks and overlays question Paul Rubin <no.email@nospam.invalid> - 2016-09-27 13:25 -0700
    Re: blocks and overlays question Mark Wills <markwills1970@gmail.com> - 2016-09-28 03:37 -0700
      Re: blocks and overlays question foxaudioresearch@gmail.com - 2016-09-28 07:41 -0700
        Re: blocks and overlays question Mark Wills <markwills1970@gmail.com> - 2016-09-28 15:05 -0700

csiph-web