Hello out there,
just wondering: In pForth (a C based Forth) there is a section called
'header' and another one called 'code', and I find something similar
in an assembler based version for eForth: some parts go into the code
segment, some other into the data segment.

What is the reason for this separation?

Helmut Giese <hgiese at (no spam) ratiosoft.com> writes:
Hello out there,
just wondering: In pForth (a C based Forth) there is a section called
'header' and another one called 'code', and I find something similar
in an assembler based version for eForth: some parts go into the code
segment, some other into the data segment.

What is the reason for this separation?

I don't know about pForth and eForth, but an idea that has been
mentioned several times is to throw away the headers after compilation
in memory-starved systems; you can then still run the program as long
as it doesn't access anything from the headers (e.g., no FIND at
run-time).
which would mean that you couldn't compile any new words, right? Thus

It requires a separation of compilation from run-time, though,
contrary to the spirit of Forth.
Well, specific requirements often win over the 'spirit'.

Hello out there,
just wondering: In pForth (a C based Forth) there is a section called
'header' and another one called 'code', and I find something similar
in an assembler based version for eForth: some parts go into the code
segment, some other into the data segment.

What is the reason for this separation? Eventually they both end up
either in RAM (in an OS based system) or in ROM (which is what I am
currently aiming for).
I am considering to just lumping the two together. However, before
investing too much work, I would like to know if there are any caveats
this way.
Thanks for any advice and best regards
Helmut Giese

Hi Anton,
Helmut Giese <hgiese at (no spam) ratiosoft.com> writes:
Hello out there,
just wondering: In pForth (a C based Forth) there is a section called
'header' and another one called 'code', and I find something similar
in an assembler based version for eForth: some parts go into the code
segment, some other into the data segment.

What is the reason for this separation?

I don't know about pForth and eForth, but an idea that has been
mentioned several times is to throw away the headers after compilation
in memory-starved systems; you can then still run the program as long
as it doesn't access anything from the headers (e.g., no FIND at
run-time).
which would mean that you couldn't compile any new words, right? Thus
it would "only" be usable as a "turn-key" system then.

It requires a separation of compilation from run-time, though,
contrary to the spirit of Forth.
Well, specific requirements often win over the 'spirit'.

Indeed.  Not many applications I've seen (embedded or otherwise)
require a compiler on board.

The ability of a forth compiler to strip out the compiler from a
turnkeyed app is a feature.  No doubt there many things contrary
to the spirit of forth, but I'd be amazed if this was one of them.

Hello out there,
just wondering: In pForth (a C based Forth) there is a section called
'header' and another one called 'code', and I find something similar
in an assembler based version for eForth: some parts go into the code
segment, some other into the data segment.

What is the reason for this separation? Eventually they both end up
either in RAM (in an OS based system) or in ROM (which is what I am
currently aiming for).
I am considering to just lumping the two together. However, before
investing too much work, I would like to know if there are any caveats
this way.
Thanks for any advice and best regards

Helmut Giese

On Jan 10, 9:54 am, John Passaniti <john.passan... at (no spam) gmail.com> wrote:
..
(like the "three instruction Forth" idea)

Is there a link where I could find more about this idea?

What people call a "three instruction Forth" is really nothing more
than a way to remotely load memory, read memory, and call a routine.

Calling such a thing a Forth requires a insanely distorted stretch of
the imagination, but the name has been around for years.

On Jan 9, 9:27 pm, "Ed" <nos... at (no spam) invalid.com> wrote:
...
The ability of a forth compiler to strip out the compiler from a
turnkeyed app is a feature. No doubt there many things contrary
to the spirit of forth, but I'd be amazed if this was one of them.

Whenever someone says something is "contrary to the spirit of Forth",
that is someone who either is pushing an agenda, or has a fixed notion
of what "the spirit of Forth" is.

Hello out there,
just wondering: In pForth (a C based Forth) there is a section called
'header' and another one called 'code', and I find something similar
in an assembler based version for eForth: some parts go into the code
segment, some other into the data segment.

What is the reason for this separation? Eventually they both end up
either in RAM (in an OS based system) or in ROM (which is what I am
currently aiming for).
I am considering to just lumping the two together. However, before
investing too much work, I would like to know if there are any caveats
this way.
Thanks for any advice and best regards
Helmut Giese

2KEYS
,
EXECUTE
...