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.