Add a vote for the "comment style" from me as well.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I didn't mention it before, but this version of IS parses. Although IS checks to see if a word is deferred or a value, (IS) doesn't care. Since Fleet Forth is ram based, not all constants that need to be changeable ( semi constants? )are values. I guess you could say that Fleet Forth has three types of constant-like words:
The hard constants are words such as 2 , 3 , C/L , and B/BUF that should be immutable. They are defined with CONSTANT .
The values are words such as COLS , #BUF , and LIMIT that one can freely change and are defined with VALUE .
The 'soft' constants are words such as MRU and LRU that need changed by one of the Forth words ( in this case CONFIGURE ), but should never be modified any other way. These words are still CONSTANTs in Fleet Forth.
If Fleet Forth were in ROM, I would need a new constant-like word, maybe SEMICONSTANT or SOFTCONSTANT , but they're a bit long.

I've just streamlined DJIFFIES , the word that takes a positive double number and waits that many jiffies ( 1/60th of a second on the Commodore 64 ) . It is also used by JIFFIES , the word that takes an unsigned single number and waits that many jiffies.
DJIFFIES works by keeping the number of jiffies to delay on the stack as well as the latest jiffy clock value. Each time through the loop, it subtracts the difference from the amount of time to wait. The idea came from DOWN-COUNTER on page 130 ( 140 of the PDF ) in the book Real Time Forth by Tim Hendtlass.
When I was testing my multitasker, I noticed that the loop in DJIFFIES runs several times per jiffy. With three background tasks, two using DJIFFIES ( actually JIFFIES ) for a delay and one counting how many times it runs, the entire round robin runs several times a jiffy. I realized that when the difference between the current jiffy clock value and the previous one is subtracted from the amount of time to delay, either 0 or -1 is added to the remaining time. I only needed to use the lower cell of the jiffy clock value. Here is the code:

JIFFIES takes an unsigned number and has a maximum delay of:
18 minutes 12 seconds and 15 jiffies.
DJIFFIES takes a positive double number and has a maximum delay of:
414 days 6 hours 3 minutes 14 seconds and 7 jiffies or
2,147,483,647 jiffies.

Here is a print dump from an interactive session where I performed a rough test on JIFFIES ( and therefore DJIFFIES .) The word TEST 'borrows' PAUSE to increment a counter once each time through the loop and resets it at the end of the test. The BASE is decimal.

So the delay loop, including the code to increment COUNTER runs about 16 times per jiffy or roughly 960 times per second.

While developing Fleet Forth, I've been using it as a testbed for Forth ideas. I'm not even sure if testbed is the right word as I have no professional programming experience.
In Fleet Forth, TYPE is a deferred word that is normally set to (TYPE). There is also the printer version, (PTYPE) , and the logger version ( to send output to both the printer and the screen ) , (LTYPE). There is a separate word, DTYPE , which is not deferred and is used to send commands to the disk drive. The only real difference is that the other TYPE words update variables for output formatting and DTYPE does not.
(TYPE) , (PTYPE) , and (LTYPE) all call PAUSE after 'typing' the string. The last two also have to clear the communications channel to the printer when they are done and before pausing. The easiest thing to do was have (TYPE) branch to CLRCHN .This requires a renaming of (TYPE) to <TYPE> and factoring out PAUSE . If I'm branching into another code word, I can't have a transition to high level to call PAUSE . Even if <TYPE> didn't branch to CLRCHN to clear the communications channel, it would still need to be a separate factor for (PTYPE) since (PTYPE) must clear the channel before pausing.

(PTYPE) would be defined as:

But I would have three words for TYPE in the kernel:
TYPE , (TYPE) , and <TYPE> .
QTYPE is similar.
QTYPE or quote type is for printing anything that may contain unprintable characters that could make the display do undesirable things, such as an index for a range of blocks or listing a block that may contain data instead of text.
Since Fleet Forth is an ITC Forth and each reference to a word is only one cell, I tried a slightly different approach. A mixing of a deferred word and a normal colon definition.

And the words which redirect output:

The idea is the first cell is the 'deferred' part followed by code common to all 'vectors' this 'deferred' word is set to execute. I know this isn't portable, but maybe it can be made portable with a new word DEFER: . Each system to use this idea would have to define their own version of DEFER: because it is system dependent. In Fleet Forth it would be something like this:

I haven't tried this yet because I'm away from my desktop ( it has the VICE Commodore simulator ) . On a large system this idea may not have much merit, but eliminating some unnecessary names on a small system may be worthwhile. At the very least, it's an idea to play with.

My implementation of DEFER: for Fleet Forth works but I don't have to implement it for what I'm doing since the words that alter the first cell in the body of TYPE and QTYPE are part of the Fleet Forth system. It is for portable use of this idea outside the system code.
One thing needed changed. -SET is a word that new DEFERred words are set to execute. It aborts showing the name of the word that is not set with the message " NOT SET". If an unset DEFERred word is used from the console, it shows that EXECUTE is not set. This is because EXECUTE doesn't nest and it's not worth the extra code to fix.
-SET works with a DEFERred word but not with a colon definition ( which is what a Fleet Forth DEFER: word effectively is ) so I defined -SET2

I realize that the following would also work:

The first way causes the DEFER: words to have a code field different from colon definitions even though the code pointed to is just a jump to do-colon. This allows words like IS to identify DEFER: words by their code field.

I reimplemented the Auxiliary stack support in the kernel. The constants identifying the location of the Aux stack were replaced with user variables and the word AP! redefined accordingly. The Aux stack can now be used by background tasks. I haven't tested this yet. It shouldn't be any more difficult than sharing the Data and Return stacks. The words >A , A> and the words built on these two are still implemented in the system loader. The versions I have are code words and the location of the Aux stack is an area of unused memory on page two. 24 cells are available for the Aux stack. >A and A> can be redefined so the Aux stack could be anywhere in memory and as large ( or small) as needed, within the constraint of available memory. Each task could even have its own Aux stack.

I have four square root words for Fleet Forth in source code on a 'library' disk. SQRT takes an unsigned double number and returns an unsigned single number. DSQRT takes an unsigned quad precision number and returns an unsigned double. They both truncate the result.
The problem is with the versions that round the result. With the truncating versions, the result of the square root of an unsigned double will fit in an unsigned single and the result of the square root of an unsigned quad will fit in an unsigned double. When the square root is rounded, the top 65,000 or so unsigned double numbers will have a result that rounds to 65536 or $10000. The top 4 billion or so unsigned quad precision numbers will return a rounded result that is 4294967296 or $100000000.
If SQRTR , the rounding version of SQRT , returns an unsigned single precision number then the result returned for those top 65,000 or so unsigned double numbers will be zero due to overflow of the result. It could be changed to return a double number to return the entire result. The high cell would be zero most of the time and one for those largest double numbers. Likewise if DSQRTR , the rounding version of SQRT , returns an unsigned double then the result for those 4 billion top numbers will be zero.
It seems odd for the rounding versions to return a different size number than their truncating counterparts. Any suggestions?

I forgot to include this in my explanation:

or maybe they should be:

or even

and I might need better names.

Hmm. Interesting problem - there will always be too many possible answers. Would it be too painful to say that these words return a full precision result, rather than half precision? That feels like the right answer, as the calling program presumably needs to be prepared to use the result, and the result might indeed be too large for half precision.

Is there a means of signalling overflow?

(I'm reminded of the difficulty in fixed-point that -1 is expressible, but +1 is not, so you can't square -1)

_________________
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?

That's a thought - a saturating rounding square root, which returns all-ones as the largest available value.

They are primitives.

Yes, they wouldn't have to be much longer. I'm looking for some consistency with the size of the returned values ( single, double, quad.)

Possibly. I'll need to give it some thought to see which I like better, that or returning a result the same size as the input.

I'm not really a fan of that one.

I don't know if there is prior code that can be a precedent for this.

Here is the code for the truncating square root word SQRT :

The rounding square root word SQRTR :

And the version of the rounding square root word which returns a double:

The version of SQRTR ( the rounding sqrare root word) which returns a double is only ten bytes longer than the one which returns a single.

Well, exact as you can be when discarding the fractional part. With the truncating version, if U squared does not equal UD then UD will be between U squared and (U+1) squared.