Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: blocks and overlays question Date: Tue, 27 Sep 2016 13:41:55 -0700 Organization: A noiseless patient Spider Lines: 41 Message-ID: <8760ph5b3g.fsf@jester.gateway.pace.com> References: <87inth5hk5.fsf@jester.gateway.pace.com> <87eg455e41.fsf@jester.gateway.pace.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="U2FsdGVkX187gBXQgN45OEkgq+PTJleT" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:hjO8cBPTPow0mHejhqc1FEu/TM0= sha1:HHPz5gfimJRF1w/ernnP6xpJHHU= Xref: csiph.com comp.lang.forth:51404 "Elizabeth D. Rather" 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?