It was able to produce very small binaries, at aprox. 40K. > (There was an option of 20k headless code kernel). > > For today standarts with the smallest pendrives working on

used a romable Fig forth, typed from the listing, and we installed this forth to give our photon counter the chance to print, communicate over serial , and send the meassurment data out

On Wednesday, September 25, 2019 at 9:56:05 PM UTC-7, dxforth wrote: > On Thursday, 26 September 2019 01:37:17 UTC+10, Rick C wrote: > > ...

Forth was ROMable when I first used it circa 1980, so there wasn't any guarantee, even back then. You could, of course, assume that VARIABLE was defined as above, but then your programs

eForth, ROMable, w/asm src > fig86.zip 38189 821119 Original Fig-86 Forth compiler > > ( http://esca.atomki.hu/simtel/msdos/forth.html ) > > The issue is: after

> > rom-able (Camel Forth or SL5 :) > > > I've watched the websites of all the three projects: DXforth, Stackworks > Forth and Camel Forth. All these systems look

in the ROMable image. In a resident system, the advantage of > segregating the headers from the code is unclear to me. > I think what you're saying is that headers might as well

generating a ROMable or flashable target. >> >> I recommend that you download trial versions of SwiftForth and SwiftX >> and read the documentation. You may also

I downloaded the 32 bit os2forth.zip from FIG's compilers page http://www.forth.org/compilers.

in a ROMable Forth compiler, making the variable a constant pointing to the variable cell. That saves the primitive right away and allows literals to be two cells per literal in a definition

mean "ROMable, packs a lot into a 16Kb image and set of 4Kb > modules". It's not just what you can measure, though. You know a well-written piece of software whan you

I have a copy of Nathaniel Grossman's article in FIG (Sept/Oct 1984) discussing continued

sort of ROM-able >bigForth is that the module system in bigForth won't work as well with >two separated memory regions per module. Hmm, the module system is bigForth-specific

. > > I don't see why the whole header must be there. Just the code field, > surely. The ROMable fields? > Andrew.- Hide quoted text - > > - Show quoted text -

32K of ROM? > >> At the current moment, I don't think so. It depends on a couple of > >> standard C functions which need something like a library. > > Assuming

Hi, I've been looking at some of the issues involved in deploying a Forth on mid-range

An interesting and thought provoking discussion. For me, Forth has a powerful, compelling feature: I

of a ROMable COLON definition, for example. IEEE 1275 Open Firmware, URL, http://playground.sun.com/pub/p1275/home.html , is the closest to a standard object format, however

to be able to run in harmony with other operating systems, be called by programs running under them and vice versa. And it should be capable of creating modules and full blown applications

consist of ROMable code for very small microcontroller-based embedded systems. Please explain why I should bother having a discussion with you when you keep insisting that I wrote

or not ROM'able .. as in pForth .. or the others are not standard enough for my liking. Put your money where your mouth is my friend, please name these amazing Forths. Keep in mind that

to be ROMable before the program is > > run. > >>> >>>What do you do for a VARIABLE, then? >> >>I use a word called RAMVAR. It makes a CONSTANT

Let me rephrase my question. How does one create the data structure of a FORTH dictionary entry in C

Does the ROMable code include the FORTH interpreter? (I believe Pro version has it) 2. Is there any licensing fee for using the FORTH interpreter/compiler etc. in our product. ie currently

Is this the fastest ROMable 6502 NEXT (that is, legacy 6502, not 65C02)? NB. either initialisation or

code is ROMable. > Is it considered *bad form* for words to modify their stored state? Please give me an example of a word with a variable internal state. My imagination is a bit slow

Suppose I want to write a function that sums the squares of two args. In C, I could write: int

t produce rom-able code without a special set of words, or does it? Conrad Weyns > It seems to me that > the issue of statically defined and initialized (eg ROM-able) unions >

Generating > ROMable code in a lot of the free embedded Forths is a major pain > in the rear. Have you looked at our SwiftX cross-compilers? All the interactivity of Forth and tiny

benefits for ROM-able forth system (where the > > > VARIABLE goes into some kind of BSS section). > > > > > In a discussion on clf it turned out that it > >