From Newsgroup: comp.lang.forth

dxf <[email protected]> writes:

DX-Forth uses a 256 byte return stack. The consequence of that is only
about 6 files can be included before it runs out.

If you mean 6 levels of nesting, that seems sufficient for a small
system. It's around 20 return stack cells for each level. Is that for
a blocks system, or do you have files? I guess it's reasonable to set
aside a chunk of dictionary or block space to use as an explicit stack,
if you want to remember filenames.

Do you use RPICK or anything like that, to get at the data for the
current level?

I still don't understand the issue with using the data stack. Maybe I
haven't thought about it enough.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16/03/2026 7:21 am, Paul Rubin wrote:

dxf <[email protected]> writes:

DX-Forth uses a 256 byte return stack. The consequence of that is only
about 6 files can be included before it runs out.

If you mean 6 levels of nesting, that seems sufficient for a small
system. It's around 20 return stack cells for each level. Is that for
a blocks system, or do you have files?

Blocks are mapped onto OS files. DX-Forth maintains a 'file descriptor
block' in memory of which there are 6. A flag in the FDB determines
whether it's a block file, text file or unused. Loading works on the
principle of a 'current file' whose pointer is saved/restored during
nesting.

I guess it's reasonable to set
aside a chunk of dictionary or block space to use as an explicit stack,
if you want to remember filenames.

A field in the file descriptor block holds the filename.

Do you use RPICK or anything like that, to get at the data for the
current level?

Not sure what you mean, but no, I use nothing fancy.

I still don't understand the issue with using the data stack. Maybe I haven't thought about it enough.

It would prevent nested files from passing data on the stack.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> writes:

It would prevent nested files from passing data on the stack.

Oh I think I understand what you mean now. LOAD can't have extra stuff
on the data stack when it transfers control to the newly loaded block or
file. But, it can use the DS temporarily while getting the new block
ready to run. It could even return after modifying the input stream
pointer so execution would continue in the new block. Location in the
old stream would have to be saved somewhere, and restored on reaching
EOF in the new block or file.

Loading works on the principle of a 'current file' whose pointer is saved/restored during nesting.

Ok but in this case why is the return stack depth a limiting factor?
The FDB pointer is just one cell, maybe even a static cell. Then you
have an array of FDB's that is used as a stack with the FDB pointer as a
stack pointer, if I understand what you mean.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16/03/2026 12:09 pm, Paul Rubin wrote:

dxf <[email protected]> writes:
...

Loading works on the principle of a 'current file' whose pointer is
saved/restored during nesting.

Ok but in this case why is the return stack depth a limiting factor?
The FDB pointer is just one cell, maybe even a static cell. Then you
have an array of FDB's that is used as a stack with the FDB pointer as a stack pointer, if I understand what you mean.

For each nest there's state stuff that needs saving (loadline# source

in blk etc). Then there's RS usage incurred during load/compile of

the current file. It all adds up. My ?STACK does a RS check which is
how I discovered 6 nested files was about the max.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> writes:

For each nest there's state stuff that needs saving (loadline# source

in blk etc).

Oh I had figured that would be in the FDB. Does it have to be on the
stack for some reason?

Then there's RS usage incurred during load/compile of the current
file. It all adds up.

I wonder if moving the state to the FDB can get rid of the need for
stack nesting. Then it's just a matter of how many FDB's you want to
set aside space for. You could even put them in the ALLOCATE heap if
you have that.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 17/03/2026 9:14 am, Paul Rubin wrote:

dxf <[email protected]> writes:

For each nest there's state stuff that needs saving (loadline# source

in blk etc).

Oh I had figured that would be in the FDB. Does it have to be on the
stack for some reason?

Then there's RS usage incurred during load/compile of the current
file. It all adds up.

I wonder if moving the state to the FDB can get rid of the need for
stack nesting. Then it's just a matter of how many FDB's you want to
set aside space for. You could even put them in the ALLOCATE heap if
you have that.

I'd have to think how that could be made to work. OTOH RS exists and
as its entire purpose is nesting, why wouldn't I use it? I don't have
ALLOCATE for various reasons. It's always struck me as black magic.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <[email protected]> writes:

I'd have to think how that could be made to work. OTOH RS exists and
as its entire purpose is nesting, why wouldn't I use it?

Do you have to do a bunch of painful juggling to get at the several
relevant RS items? And as you say, it limits you to 6 levels.

I don't have ALLOCATE for various reasons. It's always struck me as
black magic.

It gets worse. Don't ever let anyone tell you about garbage collection ;).
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 17/03/2026 11:27 am, Paul Rubin wrote:

dxf <[email protected]> writes:

I'd have to think how that could be made to work. OTOH RS exists and
as its entire purpose is nesting, why wouldn't I use it?

Do you have to do a bunch of painful juggling to get at the several
relevant RS items? And as you say, it limits you to 6 levels.

Nested files is the same as nested words with the exception there's
more to save. There's nothing about the stacked word/file that needs accessing. The data stack is used for passing information between
words/files if required.

I don't have ALLOCATE for various reasons. It's always struck me as
black magic.

It gets worse. Don't ever let anyone tell you about garbage collection ;).

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <[email protected]>,
Paul Rubin <[email protected]d> wrote:

dxf <[email protected]> writes:

For each nest there's state stuff that needs saving (loadline# source

in blk etc).

Oh I had figured that would be in the FDB. Does it have to be on the
stack for some reason?

Then there's RS usage incurred during load/compile of the current
file. It all adds up.

I wonder if moving the state to the FDB can get rid of the need for
stack nesting. Then it's just a matter of how many FDB's you want to
set aside space for. You could even put them in the ALLOCATE heap if
you have that.

Somehow in addition to buffer information you must remember the
file identification. For unix and linux that is a handle that you
get back from OPEN-FILE. That is readily stored on the return stack,
if you are not in a pinch (on a 64 bit system). If you store this in
FDB still you have stack a reference to the FDB. I don't think you
can use the data stack for that.
Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 17/03/2026 10:16, [email protected] wrote:

In article <[email protected]>,
Paul Rubin <[email protected]d> wrote:

dxf <[email protected]> writes:

For each nest there's state stuff that needs saving (loadline# source

in blk etc).

Oh I had figured that would be in the FDB. Does it have to be on the
stack for some reason?

Then there's RS usage incurred during load/compile of the current
file. It all adds up.

I wonder if moving the state to the FDB can get rid of the need for
stack nesting. Then it's just a matter of how many FDB's you want to
set aside space for. You could even put them in the ALLOCATE heap if
you have that.

Somehow in addition to buffer information you must remember the
file identification. For unix and linux that is a handle that you
get back from OPEN-FILE. That is readily stored on the return stack,
if you are not in a pinch (on a 64 bit system). If you store this in
FDB still you have stack a reference to the FDB. I don't think you
can use the data stack for that.
Groetjes Albert

Presumably the file id has to be stored with the input source data as
the specification for SOURCE-ID returns it when the source is a text
file (see 11.6.1.2218 in the standard).
--
Gerry
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16/03/2026 10:46 am, dxf wrote:

On 16/03/2026 7:21 am, Paul Rubin wrote:

dxf <[email protected]> writes:

DX-Forth uses a 256 byte return stack. The consequence of that is only
about 6 files can be included before it runs out.

If you mean 6 levels of nesting, that seems sufficient for a small
system. It's around 20 return stack cells for each level. Is that for
a blocks system, or do you have files?

Has anyone that uses libraries with interdependencies (4tH ?) calculated
their worst case nesting level? ANS specified a minimum of 8 levels.
Curious as to how that figure panned out in reality.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <[email protected]>, dxf <[email protected]> wrote:

On 16/03/2026 10:46 am, dxf wrote:

On 16/03/2026 7:21 am, Paul Rubin wrote:

dxf <[email protected]> writes:

DX-Forth uses a 256 byte return stack. The consequence of that is only >>>> about 6 files can be included before it runs out.

If you mean 6 levels of nesting, that seems sufficient for a small
system. It's around 20 return stack cells for each level. Is that for
a blocks system, or do you have files?

Has anyone that uses libraries with interdependencies (4tH ?) calculated >their worst case nesting level? ANS specified a minimum of 8 levels.
Curious as to how that figure panned out in reality.

ciforth uses blocks with locking. In a hosted system that is 16 buffers, so
16 deep nesting. As soon as a block has been LOADed it is unlocked.
For libraries residing in files:
Normally I read a file towards HERE, and during the debug session
This file is resident. So there is unlimited nesting.

It one insist on an INCLUDE-FILE were REFILL is abused to jump to
the next line. The above buffers are used for nesting and buffering. Approximately the same level of nesting.

You could increase NNBUF in the lina.fas to e.g.32

NBUF = 32 ; No. of buffers, or screens

and reassemble with
fasm ci86.lina.fas -m25600
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 21-04-2026 10:40, dxf wrote:

On 16/03/2026 10:46 am, dxf wrote:

On 16/03/2026 7:21 am, Paul Rubin wrote:

dxf <[email protected]> writes:

DX-Forth uses a 256 byte return stack. The consequence of that is only >>>> about 6 files can be included before it runs out.

If you mean 6 levels of nesting, that seems sufficient for a small
system. It's around 20 return stack cells for each level. Is that for
a blocks system, or do you have files?

Has anyone that uses libraries with interdependencies (4tH ?) calculated their worst case nesting level? ANS specified a minimum of 8 levels.
Curious as to how that figure panned out in reality.

Vanilla 4tH - unlimited inclusion files. It figures out the size, makes
space (the whole source resides in memory), includes the file, compiles
it - until it meets another INCLUDE directive.

Using the preprocessor - max. 32 levels deep. That is because it saves
the TIB and some other information on a stack.

See: https://www.youtube.com/watch?v=l4a80FS-jcA

Hans Bezemer
--- Synchronet 3.21f-Linux NewsLink 1.2