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

Groups > comp.lang.forth > #51394 > unrolled thread

blocks and overlays question

Back to article view | Back to comp.lang.forth

Contents

  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

#51394 — blocks and overlays question

Can anyone say how overlays traditionally worked in Forth?  E.g. you'd
load some program fragment with block loads, but then how would you get
rid of it when you were done?  With FORGET directly?

How much storage did it take for a block system to make any sense?
Any idea how much disk space (and ram) F83 used?

Motivation of question: wondering about the idea of an F83-like
environment inside an MCU, like one of the cheap Cortex parts with 20k
of ram and 64k or 128k of program flash, using some of the flash as
block storage.

Example: https://www.aliexpress.com/item//32369020878.html

[toc] | [next] | [standalone]

#51395

In article <87inth5hk5.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Can anyone say how overlays traditionally worked in Forth?  E.g. you'd
>load some program fragment with block loads, but then how would you get
>rid of it when you were done?  With FORGET directly?

There is hardly a tradition of overlays. The only systems that I
remember was the FysForth for the apple II.

>
>How much storage did it take for a block system to make any sense?
>Any idea how much disk space (and ram) F83 used?

I have the manual for F83 here.
This is the MSDOS era.
1. There was about 300K blocks utilities
 (with 70K free an the floppy) and 230 K for the metacompilation
 system.
If you started an application you would typically have 360 K
available in drive B: . That was a sensible amount for applications.
2. Of course this was a 16 bit Forth. A 64k space was used, because
that was available at that time.
So the segmentation of the x86 already was a restriction.

Ting adorns his block system with grandiose names like
"MASS STORAGE AND VIRTUAL MEMORY". It is in fact a simple
system where disk buffers are kept until the storage is
needed, providing a simple sort of buffering.
Such a system was already in fig-Forth and survives in ciforth.

>
>Motivation of question: wondering about the idea of an F83-like
>environment inside an MCU, like one of the cheap Cortex parts with 20k
>of ram and 64k or 128k of program flash, using some of the flash as
>block storage.
>
>Example: https://www.aliexpress.com/item//32369020878.html

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.

You also could have a look at my Renesas ciforth, with a similar
ram/flash configuration. The flash above 64k is used as a
library of blocks.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#51398

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> There is hardly a tradition of overlays. 

Oh I didn't realize that.  I know that they were used at least
sometimes.  But I guess you're saying you'd normally load some blocks
and have them stay resident "forever".  I guess that's reasonable.

> This is the MSDOS era.  1. There was about 300K blocks utilities (with
> 70K free an the floppy) and 230 K for the metacompilation system.

OK, thanks.  I see f83.com is just 25k or so, but I wondered about the
utilities.  Was it around the same in CP/M?

> 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.  I'll take a look.

> You also could have a look at my Renesas ciforth, with a similar
> ram/flash configuration. The flash above 64k is used as a library of
> blocks.

This sounds good too.  I remember playing with the 4th block editor but
the general environment was rather different from traditional Forth.

I just ran F83 under dosemu on Linux and it worked nicely, but I didn't
try any of the blocks stuff.

My idea (more a thought experiment than an intention to do anything
real) is to have a gadget with an embedded MCU, but put a Forth
interpreter in it for the purpose of allowing the user to set parameters
and customize some things.  And that leads to the desire to put in the
complete code for the device, as blocks and screens, with a block editor
etc., making it totally hackable with no external tools except a
terminal.  So I wondered if 20k ram and 64k flash was enough for that
idea to be sound, assuming it's ok for the system and utilities to use
up to half of the flash and ram.  

The specific Cortex M3 cpu on that board appears to be very cheap (less
than an Atmega328 or the like).  There's another version that's the same
except for having 128k flash, that costs several times more, though
still not much in the scheme of things.

[toc] | [prev] | [next] | [standalone]

#51401

On 9/27/16 9:36 AM, Paul Rubin wrote:
> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>> There is hardly a tradition of overlays.

It depends on what you mean by "overlay". Historically, blocks are used 
for program or application data storage. Programs could be loaded from 
source blocks. In the era of 16-bit addressing limitations, applications 
were frequently organized with common and essential functions loaded, 
with remaining dictionary space available for alternative extensions. 
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 ;

...thereby discarding the previous extension code and starting the 
compilation of this one. Some slightly more cosmetic procedures were 
also. But the essential point is that the program and extensions are 
always being compiled from source, not managed as pre-compiled code 
(which in other computing circles is what's meant by an "overlay").

> Oh I didn't realize that.  I know that they were used at least
> sometimes.  But I guess you're saying you'd normally load some blocks
> and have them stay resident "forever".  I guess that's reasonable.

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.

>> This is the MSDOS era.  1. There was about 300K blocks utilities (with
>> 70K free an the floppy) and 230 K for the metacompilation system.
>
> OK, thanks.  I see f83.com is just 25k or so, but I wondered about the
> utilities.  Was it around the same in CP/M?
>
>> 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.  I'll take a look.

Yes, there's an optional Blocks wordset. I have seen several 
implementations that use flash for source and data storage using blocks.


>> You also could have a look at my Renesas ciforth, with a similar
>> ram/flash configuration. The flash above 64k is used as a library of
>> blocks.
>
> This sounds good too.  I remember playing with the 4th block editor but
> the general environment was rather different from traditional Forth.
>
> I just ran F83 under dosemu on Linux and it worked nicely, but I didn't
> try any of the blocks stuff.
>
> My idea (more a thought experiment than an intention to do anything
> real) is to have a gadget with an embedded MCU, but put a Forth
> interpreter in it for the purpose of allowing the user to set parameters
> and customize some things.  And that leads to the desire to put in the
> complete code for the device, as blocks and screens, with a block editor
> etc., making it totally hackable with no external tools except a
> terminal.  So I wondered if 20k ram and 64k flash was enough for that
> idea to be sound, assuming it's ok for the system and utilities to use
> up to half of the flash and ram.

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

> The specific Cortex M3 cpu on that board appears to be very cheap (less
> than an Atmega328 or the like).  There's another version that's the same
> except for having 128k flash, that costs several times more, though
> still not much in the scheme of things.
>

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#51404

"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?

[toc] | [prev] | [next] | [standalone]

#51407

On 9/27/16 10:41 AM, Paul Rubin wrote:
> "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?

Any additional compilation is done at the most recent end of the 
dictionary. It's probably possible to fake it by having some unused 
space at the end of the common dictionary and then playing games with 
the dictionary pointer, but I don't know of anyone actually doing that. 
It's cleaner just to say you can't do that. If you really want to extend 
the common dictionary, you can FORGET OVERLAY, add your code, and then 
define a new overlay point.

>> 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.

Much simpler and cleaner.

>>>> 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?

Two is a minimum for decent operation. Beyond that, it really depends on 
how much RAM you have and other issues. With flash, you want to minimize 
writes. Classic Forth buffer management is a boon in that regard, 
because it doesn't write a changed buffer until the buffer needs to be 
reused (it just marks it as UPDATEd). So I would think for a flash 
system you'd want as many buffers as you have room for.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#51409

"Elizabeth D. Rather" <erather@forth.com> writes:
>> with the ability to reclaim the ram using overlays, compiling from
>> source sounds more attractive.
> Much simpler and cleaner.

I think this can even be ok even if it's compile-to-flash like with
several of the existing MCU Forths.

>> How many block buffers did a usable block system actually need
> Two is a minimum for decent operation. Beyond that, it really depends
> on how much RAM you have and other issues. With flash, you want to
> minimize writes.

Good point--if the system is logging data or otherwise frequently
updating flash pages, write wear is an issue.  If flash is only written
occasionally (like when someone edits code and saves it) then it
probably doesn't matter, if it's good for a few thousand cycles.  The
chip also has a few bytes of NVRAM in case a measurement or two needs to
be updated a lot and survive power cuts.

[toc] | [prev] | [next] | [standalone]

#51410

On 9/27/16 12:36 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> with the ability to reclaim the ram using overlays, compiling from
>>> source sounds more attractive.
>> Much simpler and cleaner.
>
> I think this can even be ok even if it's compile-to-flash like with
> several of the existing MCU Forths.

Or, you can compile your common code to flash and run it there, and use 
a little RAM for the overlays. That would require resetting the 
dictionary pointer after the flash code is compiled, but shouldn't be 
complicated.

>>> How many block buffers did a usable block system actually need
>> Two is a minimum for decent operation. Beyond that, it really depends
>> on how much RAM you have and other issues. With flash, you want to
>> minimize writes.
>
> Good point--if the system is logging data or otherwise frequently
> updating flash pages, write wear is an issue.  If flash is only written
> occasionally (like when someone edits code and saves it) then it
> probably doesn't matter, if it's good for a few thousand cycles.  The
> chip also has a few bytes of NVRAM in case a measurement or two needs to
> be updated a lot and survive power cuts.

During development, put your kernel and well-tested code in flash and 
use RAM for testing. As the code becomes more stable, add it to the 
flashed code.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#51411

"Elizabeth D. Rather" <erather@forth.com> writes:
> Or, you can compile your common code to flash and run it there, and
> use a little RAM for the overlays. That would require resetting the
> dictionary pointer after the flash code is compiled, but shouldn't be
> complicated.

Maybe there will have to be two dictionaries, flash and ram.  I'll check
how FlashForth, Mecrisp, etc. deal with this.

> During development, put your kernel and well-tested code in flash and
> use RAM for testing. As the code becomes more stable, add it to the
> flashed code.

Sounds like a plan.

Thanks for the help!

[toc] | [prev] | [next] | [standalone]

#51419

In article <8760ph5b3g.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>"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?

Source overlays were ondeed very common. We still have ALSO
that is based on having only two vocabulary's. One is Forth and
the other one is switched all the time using FORGET.

<SNIP>
>
>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.

My bad. I didn't realize you wanted a small system with blocks.
My Renesas ciforth comes close to what you have in mind though.
You can go to my site below, then renesas.html.
Or you can go directly with anonymous ftp  to
ftp://80.100.243.19/pub/renesas

>
>> 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.
My Renesas ciforth comes close to what you have in mind though.
You can go to my site below, then renesas.html.
Or you can go directly with anonymous ftp  to
ftp://80.100.243.19/pub/renesas

I toy with the idea to make something like that for noforth
to take advantage of some msp430 above 64K flash.

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

(ciforth is different. It requires as many buffers as there are levels
of nesting.)

A minimum of two. With a fast system, such as in the situation of file mapping,
 buffering makes no sense, except for editing, to be able to cancel.
A typical system with blocks on digital tape, would need about 8 buffers
to be comfortable. (digital tape would have in the order of 100 blocks
and 1 minute to go to the end.)
I remember having to load the digital block driver from cassette tape.
All this was a real pain, but the best possible before floppies came.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#51397

On Tuesday, September 27, 2016 at 11:22:19 AM UTC-7, Paul Rubin wrote:
> Can anyone say how overlays traditionally worked in Forth?  E.g. you'd
> load some program fragment with block loads, but then how would you get
> rid of it when you were done?  With FORGET directly?

You might want to look into UR/Forth, as that was the primary professional Forth system of the MS-DOS era, and it had binary-overlays.

Overlays are a big part of my Straight Forth --- this is how code-libraries get loaded. All pointers are relative to a base register; there are no absolute addresses anywhere in the code. I don't know how to implement overlays with STC --- this is why I'm using ITC rather than STC --- I would prefer STC because it is usually faster, but overlays are important enough to me that I will accept the speed loss of ITC so I can have overlays (I still expect to generate faster code than SwiftForth though; my goal is twice as fast, which is the minimum needed for writing commercial software).

UR/Forth used CS as the base register for machine-code and DS as the base register for Forth-code and data. It might seem as if you could have overlays with absolute addresses on the 16-bit x86 (this was advertised in many systems; I think Turbo Pascal claimed this) --- but you actually need to have base registers --- it is just that on the 16-bit x86 the use of CS and DS (Small memory-model ) was so common that people often used the term "absolute address" for what was actually a relative pointer.

> How much storage did it take for a block system to make any sense?
> Any idea how much disk space (and ram) F83 used?

Your question doesn't make much sense. Blocks are how source-code is stored. It is irrelevant (in regard to overlays) whether blocks or seq files are used for source-code.

The advantage of blocks is that it doesn't take much RAM. You can have as few as two blocks in RAM (that is all that UR/Forth had) and still be able to compile a big program of hundreds of kilobytes of source-code --- with seq files, if your file is hundreds of kilobytes in size, you have to have that much RAM, because you have to load the entire file into RAM.

Blocks are really just a crude form of virtual memory --- by 1970s standards, they were pretty cool --- nowadays we have better kinds of virtual memory that work with seq files, and besides that we have gigabytes of RAM so it is a non-problem now anyway.

[toc] | [prev] | [next] | [standalone]

#51399

On Tuesday, September 27, 2016 at 2:22:19 PM UTC-4, Paul Rubin wrote:
> Can anyone say how overlays traditionally worked in Forth?  E.g. you'd
> load some program fragment with block loads, but then how would you get
> rid of it when you were done?  With FORGET directly?
> 
> How much storage did it take for a block system to make any sense?
> Any idea how much disk space (and ram) F83 used?
> 
> Motivation of question: wondering about the idea of an F83-like
> environment inside an MCU, like one of the cheap Cortex parts with 20k
> of ram and 64k or 128k of program flash, using some of the flash as
> block storage.
> 
> Example: https://www.aliexpress.com/item//32369020878.html

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.

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.

TI-Forth provided a method to write out the compiled system to blocks as a binary overlay, but I believe it wrote the entire Forth system. However some clever linking and unlinking of the dictionary should have made a binary overlay to specific buffer possible.  Cross-calling of code from different overlays would however take more effort.

BF

[toc] | [prev] | [next] | [standalone]

#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.

[toc] | [prev] | [next] | [standalone]

#51428

http://turboforth.net/lang_ref/view_word.asp?id=242

:-)

[toc] | [prev] | [next] | [standalone]

#51438

On Wednesday, September 28, 2016 at 6:37:52 AM UTC-4, Mark Wills wrote:
> http://turboforth.net/lang_ref/view_word.asp?id=242
> 
> :-)

Very nice.

I remember BSAVE and BLOAD on Ti-Forth being very fast, all things considered. 
It seemed instantaneous compared to compiling source.
Turbo Forth would be faster still given the optimizations you have put in it.

[toc] | [prev] | [next] | [standalone]

#51451

On Wednesday, 28 September 2016 15:41:23 UTC+1, foxaudio...@gmail.com  wrote:
> On Wednesday, September 28, 2016 at 6:37:52 AM UTC-4, Mark Wills wrote:
> > http://turboforth.net/lang_ref/view_word.asp?id=242
> > 
> > :-)
> 
> Very nice.
> 
> I remember BSAVE and BLOAD on Ti-Forth being very fast, all things considered. 
> It seemed instantaneous compared to compiling source.
> Turbo Forth would be faster still given the optimizations you have put in it.

Yes. With a RAM disk it's pretty much instantaneous.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web