Proposal: F>R and FR> to support dynamically-scoped floating point variables

Considered

This proposal has been moved into this section. Its former address was: /standard/float

This page is dedicated to discussing this specific proposal

ContributeContributions

kc5tjaavatar of kc5tja [75] F>R and FR> to support dynamically-scoped floating point variablesProposal2019-03-03 06:20:52

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:

Word Run-time Semantics
F>R Pushes the top of the floating point stack onto the return stack.
FR> 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, FR> and 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.

MarcelHendrixavatar of MarcelHendrix

Why didn't you use an FLOCAL ?

MarcelHendrixavatar of MarcelHendrix

Why not use FLOCALs ?

BerndPaysanavatar of BerndPaysan

Probably, because there is no FLOCAL in the standard, either.

kc5tjaavatar of kc5tja

Bernd has it right; also, I was not aware of the existence of FLOCAL at the time. Thanks for the feedback; I will keep this in mind for future code!

ruvavatar of ruv

I like this idea. The F>R and FR> words can be useful to implement the DESCRIPTOR-COMPOSITE ( td*i i -- td-new ) word.

coconutavatar of coconut

Which Forth compiler supports FLOCAL? I tried Gforth, SwiftForth, VFX Forth, and bigFORTH. None of them has FLOCAL defined. Would you please give me the definition of it?

BerndPaysanavatar of BerndPaysan

The brace notation (really {: and :}) replaced words like (LOCAL), and there, you can define floating point locals with a F: word before them, i.e. {: F: r1 F: r2 :} creates two floating point locals called r1 and r2.

Gforth, bigForth and VFX supports this notation, SwiftForth doesn't.

ruvavatar of ruv

These words cannot specify how many cells on the return stack are taken (it's similar to N>R in this regard). Also, they should not be defined via execution semantics, but via compilation semantics and Run-time semantics.

  • F>R Run-time: ( F: r -- ) ( R: -- i*x )

    Remove the top item from the floating-point stack and store it as zero or more items on the return stack for later retrieval by FR>.
    Data placed on the return stack before performing these semantics are inaccessible for a program till performing the corresponding FR> Run-time semantics.

  • FR> Run-time: ( F: -- r ) ( R: i*x -- )

    Remove from the return stack the items previously stored by F>R, and place the corresponding item on the floating-point stack.

AntonErtlavatar of AntonErtl

Please advance the proposal to be more formal, along the lines of ruv's reply. One thing that you should also mention is that the return stack pointer may not comply with the usual FP alignment requirements, and your words must cope with that.

Considered
Reply New Version