Digest #322 2025-12-28
Contributions
requestClarification - Does ACCEPT saves/restores the original input buffer pointer?
My apologies, I'm new here and I hope this is the right way to do it. I'm currently writing a small Forth system for the WDC W65C02SXB board and I try to make it standard compliant as much as possible. I'm a retired computer service technician and this is just for my amusement (and maybe others that are interested). There's a thread on 6502.org where I provide a link to download my code. No fancy GitHub page, my apologies. http://forum.6502.org/viewtopic.php?f=9&t=8496
Now to my question: I ran the test for ACCEPT and it threw an error, likely because the input source is changed by ACCEPT and never restored, thus, whatever I typed in as part of the test is then now interpreted by QUIT after the test word is finished.
Is that supposed to be "the way", or is ACCEPT supposed to store the input source and then restore it? If so, I didn't find any wording saying that it should. I would greatly appreciate any clarification on this subject. Thank you very much.
Replies
requestClarification - The search order and compilation word list after a marker execution
would it it be compliant if the system restores the search order and the compilation word list?
IMO the name Execution: section needs clarification, especially the phrases "search order pointers", "other contextual information", and "is affected".
Is the compilation word list "contextual information"? Is it a "search order pointer"? I believe the answer to both of these is "yes". I believe the compilation word list is contextual information (if the Search-Order word set is present, anyway), but it is restored because it is - or refers to - a search order pointer. The "other" in "other contextual information" only makes sense if at least one of the previously discussed items is also considered contextual information.
But I'm particularly troubled by the "is affected" phrase. It doesn't fall under any of the Section 2 phrases:
In this standard, “shall” states a requirement on a system or program; conversely, “shall not” is a prohibition; “need not” means “is not required to”; “should” describes a recommendation of the standard; and “may”, depending on context, means “is allowed to” or “might happen”.
At the very least, this phrase needs clarification. As it stands, I take it to mean something like: "Whether other contextual information such as numeric base is affected is implementation defined." And I believe that phrasing is more in line with the sprit of MARKER than a direct prohibition would be.
This is not explicitly worded enough, IMO.
Block u may already be loaded in a cache/buffer.
The cache/buffer may have been modified but not flushed.
Do you execute the cache version with modifications? Do you flush the cached version first? Do you flush any other buffers that may be also LOADed by the block u being LOADed?
It seems problematic if you implement this so you have a separate 1024 block of memory that you read block u into so you can execute the disk version. You have the LOADed block maybe LOADing another block so you have to have a stack of multiple 1024 byte memory allocations.
My assumption is that LOAD should do whatever the BLOCKs system is designed to do. Find block u and if it's in memory execute it and if not an unused buffer is chosen and if none available a (perhaps) randomly chosen clean block is used and if none of those available a (perhaps) randomly chosen dirty block is written and that memory is used. If this is correct, maybe this page should reflect that information.
It's also possible to flush-buffers first. If this is correct, maybe this page should reflect that.
Possible implementation
: LOAD ( u -- , LOAD and execute BLOCK# u )
BLOCK 1024 EVALUATE
;
This uses the EVALUATE defined in the BLOCKs wordset.
This uses the
EVALUATEdefined in the BLOCKs wordset.
: LOAD ( i*x u -- j*x ) BLOCK 1024 EVALUATE ;
This is incorrect, since it does not store u in blk (as the spec requires), and even it does, evaluate will store 0 in blk.
requestClarification - Does ACCEPT saves/restores the original input buffer pointer?
Accept just waits for the user to enter some text, and what the user enters ends up in the buffer c-addr n1, with length n2 (which is <=n1). Accept does not change the input source, nor source, >in or anything else associated with the text interpreter. Quit may call accept to perform its input, but the setup of the input stream must be done by quit outside the call to accept.
requestClarification - Does ACCEPT saves/restores the original input buffer pointer?
My apologies. I should've been more patient. Soon after I posted this question I realised that I should use a temporary pointer in ACCEPT, not the default input pointer that gets overwritten and is then subsequently no longer valid. My very bad. One could say, "Duh!". ;)