On 12/12/23 02:49, mhx wrote:
> Krishna Myneni wrote:
>
>> The flocals implementation in the FSL is substantially worse. Unlike
>> using fp stack operations, one can't write re-entrant words with the
>> FSL implementation of flocals.
>
> I don't understand. This should be awkward, but ok?
>
> 8 CONSTANT /flocals
>
> : (frame) ( n -- ) FLOATS ALLOT ;
>
> : FRAME|
>        0 >R
>        BEGIN   BL WORD  COUNT  1 =
>                SWAP C@  [CHAR] | =
>                AND 0=
>        WHILE   POSTPONE F,  R> 1+ >R
>        REPEAT
>        /FLOCALS R> - DUP 0< ABORT" too many flocals"
>        POSTPONE LITERAL  POSTPONE (frame) ; IMMEDIATE
>
> : |FRAME ( -- ) [ /FLOCALS NEGATE ] LITERAL (FRAME) ;
>
> : &h            HERE [ 1 FLOATS ] LITERAL - ;
> : &g            HERE [ 2 FLOATS ] LITERAL - ;
> : &f            HERE [ 3 FLOATS ] LITERAL - ;
> : &e            HERE [ 4 FLOATS ] LITERAL - ;
> : &d            HERE [ 5 FLOATS ] LITERAL - ;
> : &c            HERE [ 6 FLOATS ] LITERAL - ;
> : &b            HERE [ 7 FLOATS ] LITERAL - ;
> : &a            HERE [ 8 FLOATS ] LITERAL - ;
>
> : a             &a F@ ;
> : b             &b F@ ;
> : c             &c F@ ;
> : d             &d F@ ;
> : e             &e F@ ;
> : f             &f F@ ;
> : g             &g F@ ;
> : h             &h F@ ;
>

The above looks ok. It has been a while since I looked at this code. The
implementation above allots space each time for new locals on entry and
frees it on exit -- I seem to be wrong about the FSL implementation
killing re-entrancy.

--
Krishna

On 12/12/23 01:00, minforth wrote:
> Krishna Myneni wrote:
>> On 12/11/23 16:42, minforth wrote:
>>> Standard Forth only defines a reduced number of fp stack operations.
>>> I added
>>> FPICK (like PICK) FROLL (like ROLL)
>>> -FROLL (like ROLL reversed)
>>> F>R R>F (already discussed)
>>> Of course this only works if the FP stack is fully accessible e.g.
>>> memory mapped.
>
>> Yes, I have added FPICK as an intrinsic word in kForth-64, and have
>> source definitions of F>R and FR> (your R>F, which is actually a
>> better name). But I think FRISE may reduce/eliminate the need for F>R
>> etc. When the FP stack resides in memory and can be accessed using a
>> pointer, it's easy to implement FRISE in source to assess its usefulness.
>
> You have defined RISE as in  2 RISE  i*x a b c d -- i*x b a c d et cetera
>
> I don't really have an application where a position swap in the depths
> of the stack would fit, because Forth operations always only use the
> top stack element(s).
>
> Then rather something like in
>  2 FLIP   i*x a b c d -- d b c a

The depth 2 RISE/FRISE would provide the function I was originally
asking for, but the general version is similar to FPICK. Admittedly,
whether the general FRISE has application for other depths remains to be
seen. Perhaps an on-fpstack sorting routine?

--
Krishna

Krishna Myneni wrote:
> The depth 2 RISE/FRISE would provide the function I was originally
> asking for, but the general version is similar to FPICK. Admittedly,
> whether the general FRISE has application for other depths remains to be
> seen.

For similar reasons I used to have a word called PATCH as a counterpart
to PICK: n PATCH overwrote the stack value in depth n, often handy to avoid
ROLLs. But in the end, such words are just crutches if you don't have locals.

> Perhaps an on-fpstack sorting routine?

Yeah, brings order to chaos ;o)

On 13/12/2023 7:43 pm, minforth wrote:
> Krishna Myneni wrote:
>> The depth 2 RISE/FRISE would provide the function I was originally asking for, but the general version is similar to FPICK. Admittedly, whether the general FRISE has application for other depths remains to be seen.
>
> For similar reasons I used to have a word called PATCH as a counterpart
> to PICK: n PATCH overwrote the stack value in depth n, often handy to avoid
> ROLLs. But in the end, such words are just crutches if you don't have locals.  

If forth be a crutch, throw it away and use something else.

On Tue, 5 Dec 2023 12:52:36 +0000
minforth@gmx.net (minforth) wrote:

[about floats with improved performance]
> Thanks for mentioning this. There is indeed a need for reduced, adaptable
> fp formats, especially in AI systems. See also the 'Motivation' section in
> https://github.com/stillwater-sc/universal
Thanks, have added that to my reference docs.

> There are already some experimental libraries using unum posits for various
> programming languages. Is there any Forth code that uses unums?

A quick route would be to buy a processor with posits[1] built-in, and install
Forth. I thought RISC-V ones were available, but looking now only found a
prototype[2], product announcement[3], and available HW designs.[4][5]

Jan Coombs
--

[1] Posits, a New Kind of Number, Improves the Math of AI The first posit-
based processor core gave a ten-thousandfold accuracy boost
https://spectrum.ieee.org/floating-point-numbers-posits-processor

[2] Researchers Build a RISC-V Chip That Calculates in Posits, Boosting
Accuracy for ML Workloads
https://www.hackster.io/news/researchers-build-a-risc-v-chip-that-calculates-in-posits-boosting-accuracy-for-ml-workloads-086b985bf0c1

[3] A Lightweight Posit Processing Unit for RISC-V Processors in Deep Neural
Network Applications
https://riscv.org/news/2021/10/a-lightweight-posit-processing-unit-for-risc-v-processors-in-deep-neural-network-applications-marco-cococcioni-federico-rossi-emanuele-ruffaldi-and-saponara-sergio-ieee-transactions-on-emerging/

[4] PERI: A Configurable Posit Enabled RISC-V Core
https://dl.acm.org/doi/fullHtml/10.1145/3446210

[5] PERCIVAL: Open-Source Posit RISC-V Core with Quire Capability
https://arxiv.org/abs/2111.15286