Where in the interpreter is the decision made whether to read from
the keyboard using KEY vs initiating a file read and pointing to a buffer?

I have these words at the top level of the outer interpreter:

WORD(accept, accept, enter, readline, interpret)
CODE(resetsp, resetsp, MOVI(SP,0xf000))
CODE(resetrsp, resetrsp, MOVI(BP,0x0100))
CODE(bye, bye, HALT)
WORD(quit, quit, enter, resetsp, accept, ok, branch, -4)
WORD(abort, abort, enter, resetrsp, lbracket, quit)
HEADLESS(cold, cold, MOVI(SI,abort+2))

I'm guessing either READLINE itself needs to figure out where to look
for input, or ACCEPT needs to fetch some parameters to pass over
to READLINE. Any guidance or ideas on this front?

On Tuesday, 27 July 2021 at 18:39:42 UTC+1, luser droog wrote:
> Where in the interpreter is the decision made whether to read from
> the keyboard using KEY vs initiating a file read and pointing to a buffer?
>
> I have these words at the top level of the outer interpreter:
>
> WORD(accept, accept, enter, readline, interpret)
> CODE(resetsp, resetsp, MOVI(SP,0xf000))
> CODE(resetrsp, resetrsp, MOVI(BP,0x0100))
> CODE(bye, bye, HALT)
> WORD(quit, quit, enter, resetsp, accept, ok, branch, -4)
> WORD(abort, abort, enter, resetrsp, lbracket, quit)
> HEADLESS(cold, cold, MOVI(SI,abort+2))
>
> I'm guessing either READLINE itself needs to figure out where to look
> for input, or ACCEPT needs to fetch some parameters to pass over
> to READLINE. Any guidance or ideas on this front?

https://forth-standard.org/standard/core/QUIT

uses refill

https://forth-standard.org/standard/core/REFILL

attempts to fill the buffer from the source.

https://forth-standard.org/standard/core/SOURCE-ID

was defined in the core extension words points to either a string or user input device ( generally keyboard )...

https://forth-standard.org/standard/file/SOURCE-ID

....but in the file access word set it also points to a file-id

On 28/07/2021 03:39, luser droog wrote:
> Where in the interpreter is the decision made whether to read from
> the keyboard using KEY vs initiating a file read and pointing to a buffer?
>
> I have these words at the top level of the outer interpreter:
>
> WORD(accept, accept, enter, readline, interpret)
> CODE(resetsp, resetsp, MOVI(SP,0xf000))
> CODE(resetrsp, resetrsp, MOVI(BP,0x0100))
> CODE(bye, bye, HALT)
> WORD(quit, quit, enter, resetsp, accept, ok, branch, -4)
> WORD(abort, abort, enter, resetrsp, lbracket, quit)
> HEADLESS(cold, cold, MOVI(SI,abort+2))
>
> I'm guessing either READLINE itself needs to figure out where to look
> for input, or ACCEPT needs to fetch some parameters to pass over
> to READLINE. Any guidance or ideas on this front?
>

Forth-79 had no concept of 'files'. Input came from console (BLK=0)
or blocks (BLK<>0).

ANS introduced SOURCE-ID which extends BLK=0. When BLK is 0, input
is from console, files or EVALUATE as determined by SOURCE-ID.
Thus REFILL in QUIT must first examine BLK; if zero then it examines
SOURCE-ID.

luser droog <luser.droog@gmail.com> writes:
>Where in the interpreter is the decision made whether to read from
>the keyboard using KEY vs initiating a file read and pointing to a buffer?
>
>I have these words at the top level of the outer interpreter:
>
>WORD(accept, accept, enter, readline, interpret)
>CODE(resetsp, resetsp, MOVI(SP,0xf000))
>CODE(resetrsp, resetrsp, MOVI(BP,0x0100))
>CODE(bye, bye, HALT)
>WORD(quit, quit, enter, resetsp, accept, ok, branch, -4)
>WORD(abort, abort, enter, resetrsp, lbracket, quit)
>HEADLESS(cold, cold, MOVI(SI,abort+2))
>
>I'm guessing either READLINE itself needs to figure out where to look
>for input, or ACCEPT needs to fetch some parameters to pass over
>to READLINE. Any guidance or ideas on this front?

As others mention, in the standard you have REFILL that decides
internally based on what the input source is.

Classically, you don't have REFILL. The various words (QUIT for
terminal input, LOAD for blocks, and later INCLUDE for files, and
EVALUATE) set up TIB and #TIB (SOURCE in the standard), and then call
INTERPRET.

In the standard ACCEPT is a word for reading from the terminal that
does not interpret.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> ... The various words (QUIT for
> terminal input, LOAD for blocks, and later INCLUDE for files, and
> EVALUATE) set up TIB and #TIB (SOURCE in the standard), and then call
> INTERPRET.

I think I've mentioned an early bug in ForthOS; I pointed the TIB at
the block in its entirety (4k source screen in ForthOS). Elegant, I
thought, but it breaks when the source uses a word which ends at the
80th column; when viewed as a single 4k block, that word "wraps" to
whatever text follows at the first column of the next line.

So a little extra complexity, walking a line's worth of the buffer
at a time fed into the TIB, as source input walks down the buffer.
I almost convinced myself to just never use the last column, but it
was too far against the principle of least astonishment.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Andy Valencia schrieb am Mittwoch, 28. Juli 2021 um 15:27:49 UTC+2:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > ... The various words (QUIT for
> > terminal input, LOAD for blocks, and later INCLUDE for files, and
> > EVALUATE) set up TIB and #TIB (SOURCE in the standard), and then call
> > INTERPRET.
> I think I've mentioned an early bug in ForthOS; I pointed the TIB at
> the block in its entirety (4k source screen in ForthOS). Elegant, I
> thought, but it breaks when the source uses a word which ends at the
> 80th column; when viewed as a single 4k block, that word "wraps" to
> whatever text follows at the first column of the next line.
>
> So a little extra complexity, walking a line's worth of the buffer
> at a time fed into the TIB, as source input walks down the buffer.
> I almost convinced myself to just never use the last column, but it
> was too far against the principle of least astonishment.
>

Yes, that was "an old surprise". :-)
Evaluating 1k of one block in one go looks so attractive...

Andy Valencia <vandys@vsta.org> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> ... The various words (QUIT for
>> terminal input, LOAD for blocks, and later INCLUDE for files, and
>> EVALUATE) set up TIB and #TIB (SOURCE in the standard), and then call
>> INTERPRET.
>
>I think I've mentioned an early bug in ForthOS; I pointed the TIB at
>the block in its entirety (4k source screen in ForthOS). Elegant, I
>thought, but it breaks when the source uses a word which ends at the
>80th column; when viewed as a single 4k block, that word "wraps" to
>whatever text follows at the first column of the next line.

That's the same with standard screens since Forth started, except that
screens are 1K chars and screen-lines are 64 chars; but screen-lines
only play a role for "\" and for LIST; for LOAD the whole screen is a
line.

>So a little extra complexity, walking a line's worth of the buffer
>at a time fed into the TIB, as source input walks down the buffer.
>I almost convinced myself to just never use the last column, but it
>was too far against the principle of least astonishment.

Somehow screens fell out of fashion before standard Forth got this
far.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Wednesday, July 28, 2021 at 11:48:45 AM UTC-5, Anton Ertl wrote:
> Andy Valencia <van...@vsta.org> writes:
> >an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >> ... The various words (QUIT for
> >> terminal input, LOAD for blocks, and later INCLUDE for files, and
> >> EVALUATE) set up TIB and #TIB (SOURCE in the standard), and then call
> >> INTERPRET.
> >
> >I think I've mentioned an early bug in ForthOS; I pointed the TIB at
> >the block in its entirety (4k source screen in ForthOS). Elegant, I
> >thought, but it breaks when the source uses a word which ends at the
> >80th column; when viewed as a single 4k block, that word "wraps" to
> >whatever text follows at the first column of the next line.
> That's the same with standard screens since Forth started, except that
> screens are 1K chars and screen-lines are 64 chars; but screen-lines
> only play a role for "\" and for LIST; for LOAD the whole screen is a
> line.
>
> >So a little extra complexity, walking a line's worth of the buffer
> >at a time fed into the TIB, as source input walks down the buffer.
> >I almost convinced myself to just never use the last column, but it
> >was too far against the principle of least astonishment.
> Somehow screens fell out of fashion before standard Forth got this
> far.
> - anton

That does seem to be the case. I've decided to try to implement screens,
however. Both for *historicity*, and coolness factor (for being so bizarre),
and because it offers a simple way for me to embed high level forth
source directly into my program. So I can have some high level "config code"
which is editable in my C source as some space-padded strings that
get copied into memory in the forth_init() code.

It seems like a step in the right direction for the goal of completing F79
features and moving forward to later standards. It also lets me start
writing actual Forth source code, rather than comma-separated lists
of addresses in the arguments to a varargs macro.

Going straight to files would serve this latter goal but not all the others.

On Wednesday, July 28, 2021 at 11:48:45 AM UTC-5, Anton Ertl wrote:
> Somehow screens fell out of fashion before standard Forth got this
> far.

I very much like block files and screens. The way they work is neat.
Can't justify them but I wouldn't have a Forth without them.
With them one has virtual memory for tables and the block access can
easily be modified to point to memory thus having ram disk, maybe a place
for storing working strings.
--
me

In my current Forth I haven't bothered to implement INCLUDE and INCLUDED
just implemented FLOAD and a single 4K buffer for file reads. Get by
just fine. The one downside is a file being loaded can't include another
file and then continue with it's load. But it can load a needed file and
put out a message to reload. The second attempt now having the required
code then loads. The file can, however, load any needed code from block
files since they have their own buffers. Not saying this is the way
file reads should work but saying that you can get by this way with very
little pain.
--
me

luser droog <luser.droog@gmail.com> writes:
> ... I've decided to try to implement screens,
> however. Both for *historicity*, and coolness factor (for being so bizarre)
> ...

If your experience is anything like mine, you'll be surprised at how _not_
bizarre working with source screens is. I ended up with a thin layer of
"file system" to organize the blocks:

http://sources.vsta.org/forthos/fs.html

and then an editor which knew how to play with them, including being able to
insert/delete a screen block into an existing source "file":

http://sources.vsta.org/forthos/vi.html

The result is a filesystem which is stupidly durable, and source code which
is perfectly convenient to work with. In its entirety quite approachable to
understand or modify, and living within a very modest memory budget.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On 29/07/2021 04:18, S Jack wrote:
> On Wednesday, July 28, 2021 at 11:48:45 AM UTC-5, Anton Ertl wrote:
>> Somehow screens fell out of fashion before standard Forth got this
>> far.
>
> I very much like block files and screens. The way they work is neat.
> Can't justify them but I wouldn't have a Forth without them.
> With them one has virtual memory for tables and the block access can
> easily be modified to point to memory thus having ram disk, maybe a place
> for storing working strings.

Very comfortable using 'screen files' and editor for forth source. It
became 'unfashionable' at a time when Forth was desperately trying to appeal
to those who were never going to accept Forth, no matter what. Circa 1989
and ANS:

<[Mitch] PRESS16> Sun Microsystems: Leading supplier of technical
workstations, has grown to $1 billion annual sales in 6 years. I've been
there since 1982 (employee #50, now over 7500 employees). Bradley Forthware:
My home company. Supplies Forth for 680x0 machines (Atari ST, Macintosh, Sun,
others) and SPARC machines (Sun, single board).
Past Use of Forth at Sun:
- "Unofficial" bringup standalone diagnostics.
- A small number of Unix-based tools.
Current Forth work at Sun:
- Developing new Forth-based firmware for Suns; will probably become the
standard firmware shipped with Suns sometime in the future.
- Forth is used as an interactive monitor and as a CPU-independent language
for "plug-in" boot drivers (not Unix drivers; they're still written in C)
My (perhaps) controversial beliefs:
- Forth needs to "grow up".
- The "minimalist" Forth philosophy is responsible for Forth's relative lack
of success.
- Screens suck.
- Forth's portability problems are due to disregard of reality.
- C has its advantages
- Forth chips are no big deal.

Andy Valencia <vandys@vsta.org> wrote:
> luser droog <luser.droog@gmail.com> writes:
>> ... I've decided to try to implement screens,
>> however. Both for *historicity*, and coolness factor (for being so bizarre)
>> ...
>
> If your experience is anything like mine, you'll be surprised at how _not_
> bizarre working with source screens is. I ended up with a thin layer of
> "file system" to organize the blocks:
>
> http://sources.vsta.org/forthos/fs.html

I did something similar in SOL-86 (http://t3x.org/bits/hypersol.html),
but even simpler. Each block has a header of the form

(L nnnnn mmmmm comment ... )

where nnnnn links to the previous block (or 0) and mmmmm links to the
next block (or 0). ALLOCATE allocates a block from a block bitmap and
RELEASE frees a block. Makes it really easy to insert/delete blocks
in the middle of programs and keeps much of the simplicity of pure
blocks. The editor has commands for handling linked lists of blocks.

--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org

On Wednesday, July 28, 2021 at 12:28:53 AM UTC-5, Anton Ertl wrote:
> luser droog <luser...@gmail.com> writes:
> >Where in the interpreter is the decision made whether to read from
> >the keyboard using KEY vs initiating a file read and pointing to a buffer?
> >
> >I have these words at the top level of the outer interpreter:
> >
> >WORD(accept, accept, enter, readline, interpret)
> >CODE(resetsp, resetsp, MOVI(SP,0xf000))
> >CODE(resetrsp, resetrsp, MOVI(BP,0x0100))
> >CODE(bye, bye, HALT)
> >WORD(quit, quit, enter, resetsp, accept, ok, branch, -4)
> >WORD(abort, abort, enter, resetrsp, lbracket, quit)
> >HEADLESS(cold, cold, MOVI(SI,abort+2))
> >
> >I'm guessing either READLINE itself needs to figure out where to look
> >for input, or ACCEPT needs to fetch some parameters to pass over
> >to READLINE. Any guidance or ideas on this front?
> As others mention, in the standard you have REFILL that decides
> internally based on what the input source is.
>
> Classically, you don't have REFILL. The various words (QUIT for
> terminal input, LOAD for blocks, and later INCLUDE for files, and
> EVALUATE) set up TIB and #TIB (SOURCE in the standard), and then call
> INTERPRET.
>
> In the standard ACCEPT is a word for reading from the terminal that
> does not interpret.
>
> - anton

Belated thanks to everyone for the help. I'm somehow finding it hard
to actually get going and dig in and do the work on this. I've been
reading through all my core literature. In the past 3 months I've read
Starting Forth, Norton's Guide to the IBM PC, Advanced MSDOS
Programming by Ray Duncan, Undocumented DOS, Forth by Salman
et al., and Loeliger's Threaded Interpretive Languages. And now I'm
slogging through Thinking Forth and Stephen Morse's The 286
Architecture.

I first tried to make a minimal change that wouldn't break anything
by moving the call to INTERPRET out of ACCEPT and up higher
in QUIT after ACCEPT returns. But that broke the interpreter because
then my hard coded relative branch was off by one. The macros
that helped with branching in the assembly code came in useful here.
I was able to replace the hard coded branch offset with a "soft coded"
one.

Next to tackle actually reading from a screen. Part of the stumbling
block is that there appears to be a partly written *attempt* at
what I need just floating around in my definitions. I have written a
word called WORD2 which looks very close to the code for WORD
from the 8086 fig forth. My actual code for WORD is just whatever
cockamamie gumwad I hacked up to get something kinda working.
So it appears that I not only need to figure out all the things I need
to write that aren't there but how much vestigial proto-code is buried
in there and whether it helps or not. Even to delete it and start with
a cleaner slate I have to tease apart whatever "molecule" it's
connected to.

Accentuating the positive, I made the small change to ACCEPT
so it does not call INTERPRET but just reads in a line. And in so
doing, I also had to make the branching for the loop in QUIT
more robust and easier to read (-ish).

So screens first, then files. Wish me luck.