One of the cool features that Gforth offers is the ability to "vectorize" EMIT, TYPE and KEY. Slightly simplified, EMIT is actually a "default" routine (EMIT), which at start up is linked to EMIT as DEFER EMIT followed by (EMIT) IS EMIT. This allows the user to redirect the output.

However, since none of this is in ANSI, there are some questions. If I redirect EMIT, should TYPE automatically be redirected as well? What about error messages and other output?

Currently, I'm favoring the idea of making EMIT and TYPE separate so the user has the flexibility to keep them separate, especially because it isn't to hard to redirect both. Harder is if I want to make error output vectorizable, because on the one hand it is nice to have a central "console", on the other hand it doesn't seem to make much sense to move everything to (say) another terminal and not show the user there the output.

Does anybody have experience with these questions? Any recommendations?

EDIT: Forgot to add the link to Gforth's take on this: https://www.complang.tuwien.ac.at/forth ... ction.html Note that it calls this "Redirection" and offers two levels: One via a file (and Liara Forth doesn't have files), and one via DEFER. Both EMIT and TYPE need to be redirected separately.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Having a separate error channel for diagnostics would make sense, but EMIT and TYPE should probably follow each other rather closely, due to the fact that the Forths I've disassembled so far all call EMIT from within TYPE. I haven't delved too deeply into KEY and friends yet.

Mike B.

Depending on how the vectoring is done, would determine what you would need to do.

For example, the way DEFER works in F83 (and I have no reason to suspect that it's unique in this regard) is something like this:

So, if TYPE is implemented using EMIT, and EMIT is vectored (or DEFERed), then TYPE does not need to change, only EMIT.

So you could do something like:

Very interesting, thanks -- ANSI has SOURCE-ID to tell you where stuff is coming from, maybe something OUTDEV could be realized as DESTINATION-ID and decided were stuff goes to. Will go off and stare are my code for a while ...

EMIT, TYPE, and EXPECT are defered on my system for the C64 . I have three words for redirecting output:
CONSOLE directs output from EMIT and TYPE to the video screen.
PRINTER directs output from EMIT and TYPE to the printer.
LOGGER directs output from EMIT and TYPE to the video screen and the printer. EXPECT is vectored so that in addition to doing its usual job it also sends a copy of what is expected to the printer.
This is really handy to make a log of an interactive session at the computer.
BTW since I am using VICE, I don't have a printer set up. The simulator sends all printed text to a print.dump file.

My very first embedded Forth was on the R6511AQ chip where I bought and cloned the RSC-Forth ROMs and modified the machine code by hand. I think I could still read R6502 machine code to this day
RSC-Forth was based on Fig Forth but used vectors for (EMIT) and (KEY) and also (KEY?) IIRC. I used this extensively in my POS terminal designs where output would be redirected to displays and printers and even video. When I eventually created my own fresh source years later it was for the 65C816 (and then for the 65C02 for a volume product). Because I was used to using vectors and they were so useful, I used the same technique in my Forth. One thing I did was standardize the character coding so that for example a "clear screen" character would work the same across all output devices. I later enhanced this Forth to work with the M37702 which was a super-set of the 65C816, and used this MCU in many products for many years.

Nowadays I mainly work with the Parallax Propeller chip, especially the new P2 and this technique has been carried through from all my embedded products. I find though that some of the complicated command channel stuff I did by sending data to the (KEY) vector (one of which was to actually read input) etc is no longer necessary. I just have (EMIT) and (KEY) but KEY always returns a null if there is no input, and if it a raw binary device that could send a 00 then I simply OR it with $100. So KEY is non-blocking and instant, it is never trying to wait for input.

With (EMIT) it is always a blocking emit because I find that no matter how much buffering I might have, it is easy to fill that buffer so most of my output stuff is no buffered and way more efficient, especially if I use high baud rate for serial etc.

So the main takeaway is that there is no KEY? word, just KEY, and if it returns a zero then there is no input. However, KEY and especially EMIT are normally two good places for PAUSE because most I/O is inherently slow.

So, one day I will like to revisit the 65C02/65C816 and write a brand new Forth that embodies many of the techniques and things I have learned over the years.

BTW, there is no PAUSE in my multi-core Tachyon Forth on the Parallax P1 and P2 simply because each task can have its own CPU.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?