Marcel,

Thanks for your response. FLOCALS is a real problem for me, because I have
to write a lot a complicated math formulas.

Again, sorry about my bad english.

> > FLOCS|
> > 3,1416e FLOCS| alpha beta x y pi |
> > Prepare and initialize local float FVALUES in a definition.
> > Not case sensitive.
>
> This word suspiciously looks like LOCALS| , but expects the values in
> reverse order. I'd recommend either using a different name ( perhaps
> F{ } because { } has the stack picture you seem to want ), or reverse
> the initialization sequence.
-------
I think you are right. Now I am using this syntax: F{ alpha beta ... }

(Nota: Unfortunately, {...} is used to comment section of code in
SwiftForth...
So I must take care when using those {comments}.)

> BTW, iForth has had the word FLOCALS| since many years now, with
> the LOCALS| order.
----------
I think SwiftForth don't have FLOCALS|. Its why I am interested to write a
equivalent system to clarify my source code. Also I try to experiment the
idea of using a "local interpreter" to manage specials Forth sources
fragments.

> > FTO
> > 3.14e FTO pi
> > Store float value.
>
> Why not TO ?
-------
I think FTO is better:

- TO get a value from the data stack.
- FTO get a value from the numeric stack

        ... 45e FTO Alpha ... 0 TO i ...

Its not the same. Reading FTO I know that the numeric-stack is used, not
the data stack. Its more readable without losing efficacy.

> > FADR>
> > FADR> alfa
> > Returns the float variable address.
>
> This will create more problems than you perhaps expect. An obvious
> one (that no Forther cares about :) is that the compiler now can't
> keep flocals in registers. A second is that it is easy to pass the
> address of a local to an out-of-scope routine. That would be a
> spectacular bug. Third, you may want to pass these addresses to
> the OS. But in that case (apart from problem #2) you need to know
> the size of a float, or have more FTO's ( SFTO DFTO FFTO ) or have
> more FLOCALS|s (SFLOCALS| .. ).
>
> I have no clear answer to this, but if I have time, it will
> probably be DFVALUE , DFLOCALS| and an even smarter TO .
--------
You are right again, and probably I never need to use this possibility.
Finally I can remove FADR>.

But remember that Forth is not a "typed language". Writing the following:

        : SUM ( i j -- i+j ) + ;

SUM "expect" two integer. If you pass adresses or anything bad, SUM take
two values from the stack, and execute the addition... and this can also
result in a spectacular bug.

About passing floats to the OS ( or 'C' code in general ) I have send a
previous mail with a partial solution - only for single floats. Again
today, I cannot how to pass double-floats to a standard DLL!

>
> > ENDFLOCS
> > To use when exiting definition before semi-colon ;
>
> This word should be superfluous.
---------
It should be, but in that case I must redefine EXIT, ?EXIT and also any ;M
etc. or possibly define some FEXIT ?FEXIT ... ?

>
> Did you look at the FSL code for flocals? It only allows a few fixed
> names, but it would be easy to fix that.
----------
Yes. FSL use a good and simple solution. But...

But with few fixed names (a b .. g h), I cannot really name the stack
values, and I think its not trivial to extend the FSL solution.

The resulting code is again difficult to read: when writing formulas with
Forth RPN notation, I expect to have correct variable naming:

        : Area ( n: radius alfa beta -- area )
                F{ radius alfa beta }
                radius FDUP F* FPI F*
                alfa beta F- .... ;

        : Area ( n: radius alfa beta -- area )
                FRAME| h a b |
                h FDUP F* FPI F*
                a b F- ... FRAME| ;

>
> [..snip a surprising amount of code..]
>
---------
This amount of code have two part:

The first part is a idea of reusable "local interpreter". I plane to reuse
the
external word I{ to do other things. For example:

        : LOCAL-MATRIX-SYNTAX{
                ...
                c" }" ['] (MATRIX-SYNTAX-INTERPRETER) I{ drop
                ... ;

The second part is the flocals code. Comparing the "amount" of code with
the FSL, you can see why my code is more complicated:

        -manage a float-stack no using the "here" dictionary space
        -manage a true symbol table
        -check for name collision

But probably its possible to write the same thing with less lines...

> > \ Example : (^) ( n: x y z u v w -- a b c )
> > \ -------
> > \ where a b c is the vector product
> > \ a = y*w - v*z
> > \ b = z*u - w*x
> > \ c = x*v - u*y
>
> > : (^) ( f: x y z u v w -- a b c )
> > FLOCS| x y z u v w |
> > y w f* v z f* f- \ f: a
> > z u f* w x f* f- \ f: a b
> > x v f* u y f* f- ; \ f: a b c
>
> It's hard to believe you are going to copy these vectors to and from
> the stack all of the time.
-----------
Having six floats numeric values on the stack is probably near a maximum,
but its frequent in 3D programs: the x,y,z values are points or vectors.
Often, those values comes from memory, but not always...

>
> FLOAT DARRAY X{
> FLOAT DARRAY Y{
> FLOAT DARRAY Z{
>
> X{ 3 }FREAD
> 1 2 3
>
> Y{ 3 }FREAD
> 2 3 4
>
> Z{ 3 }FREAD
> 0 0 0
>
> : (^) ( x{ y{ z{ -- )
> DUP DIMS NIP LOCALS| n z{ y{ x{ |
> n 0 ?DO x{ I } F@ y{ I } F@ F- z{ I } F! LOOP ;
>
> X{ Y{ Z{ (^) Z{ }print
-------------
OK, but you are using static variables. Its the same as using the simple
solution and deniate the "float-stack-gymnastic" problem:

        fvariable x y z u v w \ static alloted variables

        : ((^)) ( n: nothing -- a b c )
            y f@ w f@ f* v f@ z f@ f* f- \ n: a
            z f@ u f@ f* w f@ x f@ f* f- \ n: a b
            x f@ v f@ f* u f@ y f@ f* f- ; \ n: a b c

>
> \ 2000000 Test
> \ 9143 with flocals>
> \ 10946 with normal method
>
> : Test ( -- )
> cr timer-reset
> #2000000
> 0 DO X{ Y{ Z{ (^) LOOP
> .ELAPSED ;
>
> Test ( 166MHz P2 )
> 5.052 seconds elapsed. ok
>
> -marcel
>
----------
I cannot compare _absolute_ timing because of computer difference.

        SwiftForth 1.50.4 21 Jan 1999
        2000000 test 10606 11536 ok
        10606e 11536e f/ f. 0.9193828 ok ( ? )

Regards,
Charles

.
Received on Fri May 28 1999 - 13:00:39 PDT