Digest #49 2019-03-05
In writing an implementation of map and reduce operations for some floating point vectors, I've had a need to save and restore dynamic variables on the R-stack. Some of these variables are floating point variables.
The lack of a floating-point stack equivalent to R> and >R made this more difficult than it should have been, I think. Therefore, I'd like to propose the following two words for consideration in the FLOATING-EXT wordset:
||Pushes the top of the floating point stack onto the return stack.|
||Pops the return stack, pushing the value removed onto the floating point stack.|
On systems where the return stack cell size differs from the floating point stack cell size, multiple cells may need to be pushed onto the R-stack, padding as appropriate. Because of alignment issues,
F>R are not guaranteed to be fast, as the implementation may have to store the floating point value in smaller parcels (e.g., storing a 64-bit or 80-bit FP value as a series of 16-bit cells on a 16-bit Forth).
Here's my current implementation written in 64-bit GForth 0.7.0 on x86-64 platform:
FVARIABLE realvar : F>R ( r -- ) ( R: -- r ) R> realvar F! realvar @ >R >R ; : FR> ( R: r -- ) ( -- r ) R> R> realvar ! realvar F@ >R ;
I'd love to hear your thoughts. Thanks for entertaining my idea.
We had that in Gforth, but removed it, because it was too smart. Example:
postpone (. You can't really know what some Forth code actually does unless you actually interpret it, which the
[ELSE] scanner doesn't.
\ The following was too smart for its own good; consider "postpone (". \ Moreover, ANS Forth specifies that the next [THEN] ends an [IF] \ (even if its in a '( ... )'). \ ' ( Alias ( immediate ( keep fontify happy) \ ' \ Alias \ immediate
Yes, if I uncomment these two aliases, you can comment out an
The specification of [IF] is clear:
parse and discard space-delimited words from the parse area [...], until either the word [ELSE] or the word [THEN] has been parsed and discarded.
So \ and ( and everything else except [ELSE] and [THEN] will just be discarded (with [IF] increasing a nesting counter in addition). No clarification for \ needed in the normative text. If you think that users need a clarification, you can put it in your system's documentation, in a contribution here, or you can propose a change to the Rationale of [IF], [ELSE], and/or [THEN]
When 0 [IF] is scanning for [ELSE] then a string containing [IF] [ELSE] or [THEN] will cause a problem e.g.
0 [if] s" [else] or [then] follow [if]"
will either underflow due to the OR or fail to recognise FOLLOW (unless FOLLOW is defined. of course).