Floating point in ANS Forth 
Author Message
 Floating point in ANS Forth

The ANS Forth TC is reviewing floating point requirements.  Skip Carter,
head of the FSL effort, has recommended two things:

1) Discarding the entitlement for integrated fp/data stacks, and mandating a
separate fp stack.

2) Enlarge the minimum fp stack size to 16 items.

Here's some of the discussion so far.  I'd appreciate comments from those of
you that write a lot of fp code.

Regarding #1, Greg Bailey has written:

Quote:
>GBWith regard to separate/joined stacks, the intent was to allow the
>optimal use of some hardware (such as Harris and for that matter
>Novix) whose architecture directly supported the data stack so well
>that their designers overlooked providing the registers, data paths,
>and increment/decrement circuitry that would have been necessary to
>implement additional stacks on those machines.

>GBMy opinion as one who has written a fair amount of software for the
>Novix processor is that the absence of such data indexing capability
>is in reality a serious flaw in its design, and one which I had to
>continually circumvent with great expenditure of thought and if I
>may say so cleverness.  In retrospect this feature is a great weak-
>ness that afflicts many things besides just implementation of a
>floating point stack.  Bottom line is that hardware with this
>paucity of registers requires use of very unusual and constrained
>practices for optimal performance.

To which I responded:

Quote:
>EDR  I'm happy to ditch the separate stack, but note that there are
>a large number of users of URForth (LMI) with integrated stacks.
>One of them was even talking about porting Ray's FP package to
>SwiftForth to avoid rewriting his applications that assumed integrated
>stacks (don't know if he actually did).  So there's potential for mad

users.

Regarding point #2, Skip observes:

Quote:
>SC  Experience with the Forth Scientific Library demonstrates that
>in the course of evaluating various mathematical functions that float
>stack depths of 6 are readily reached  which forces either a
>presumption of an environmental dependency for a deeper stack,
>or designing the functions to use scratch variables which introduce
>other problems with the use of these functions.

Greg suggests:

Quote:
>GB So, another way to handle (2) that would I think be consistent
>with the way we address this same issue for the data stack would
>be to delete the specification of any minimum at all.  In the
>rationale we point out that as a practical matter systems had
>better provide some way for an application programmer to *obtain*
>whatever his application requires, and that this specifically
>means that placing *either* stack in a hardware resource whose
>size is architecturally bounded at some small limit will in turn
>severely limit the range of Standard programs it may expect to
>run.

My observation:

Quote:
>EDR As to stack depth, we released SwiftForth with FP stack
>in memory, and after a firestorm of protest from customers we
>made hw/sw stacks a configuration option.  IMO it's a mistake
>to _prevent_ customers from writing optimal code.  If we make
>a large minimum stack depth, implementors will be constrained
>from supporting hardware stacks.  I'd rather leave the burden
>on the program to document the minimum stack depth it needs.

I'm particularly interested in hearing from those of you supporting
significant applications involving floating point, who might be
most affected by these decisions.

I'm especially interested in any information as to the prevalence
of integrated fp stacks; several people have asserted confidently
that "nobody" does it that way, and although I'm all for a separate
fp stack, I suspect that there is a body of existing integrated-stack
code out there that could cause trouble.

Thanks,
Elizabeth

that might



Mon, 26 Nov 2001 03:00:00 GMT  
 Floating point in ANS Forth
Though I am not part of the audience your message targets, I do have one perspective that may help.

I am a novice Forth programmer (with 17 years experience in other languages for embedded systems), and am struggling mightily with designing the Forth code to implement a bunch of {*filter*} math for an avionics application (ODEs, derivatives, exponentials).

Factorizing my math feels more like generating Cantor's Dust than solid code.  Several of my algorithms have complex states, and I'd like to be able to allocate separate FP stacks for each of them.  Presently, I use large arrays for state and historical data (such as for adaptive moving window averages), and I wish I were able to use Forth stack operators on these data structures, instead of my own slow code for manual indexing and copying operations.  The only new words needed would be for copying between these allocated stacks, and would look alot like those for the D and R stacks, but with at least one additional stack parameter specifying the stack(s) involved.

What about having one small "global" FP stack (possibly integrated), and a mechanism for creating and using additional separate non-integrated FP stacks?  Allowing a "stack" to be a user data object would prevent the needless emulation of core words that are already optimized to near perfection.  I want to use THAT code to manipulate my data, not my slow emulation of that code!

Hmmm...  Do this with _all_ the stacks, and Forth could multi-task/multi-thread (switch all stack pointers = context switch).  Yes?

But then again, I am but a newbie...

- Bob "Grasshopper" Cunningham

Quote:

> The ANS Forth TC is reviewing floating point requirements.  Skip Carter,
> head of the FSL effort, has recommended two things:

> 1) Discarding the entitlement for integrated fp/data stacks, and mandating a
> separate fp stack.

> 2) Enlarge the minimum fp stack size to 16 items.

> Here's some of the discussion so far.  I'd appreciate comments from those of
> you that write a lot of fp code.

> Regarding #1, Greg Bailey has written:

> >GBWith regard to separate/joined stacks, the intent was to allow the
> >optimal use of some hardware (such as Harris and for that matter
> >Novix) whose architecture directly supported the data stack so well
> >that their designers overlooked providing the registers, data paths,
> >and increment/decrement circuitry that would have been necessary to
> >implement additional stacks on those machines.

> >GBMy opinion as one who has written a fair amount of software for the
> >Novix processor is that the absence of such data indexing capability
> >is in reality a serious flaw in its design, and one which I had to
> >continually circumvent with great expenditure of thought and if I
> >may say so cleverness.  In retrospect this feature is a great weak-
> >ness that afflicts many things besides just implementation of a
> >floating point stack.  Bottom line is that hardware with this
> >paucity of registers requires use of very unusual and constrained
> >practices for optimal performance.

> To which I responded:

> >EDR  I'm happy to ditch the separate stack, but note that there are
> >a large number of users of URForth (LMI) with integrated stacks.
> >One of them was even talking about porting Ray's FP package to
> >SwiftForth to avoid rewriting his applications that assumed integrated
> >stacks (don't know if he actually did).  So there's potential for mad
> users.

> Regarding point #2, Skip observes:

> >SC  Experience with the Forth Scientific Library demonstrates that
> >in the course of evaluating various mathematical functions that float
> >stack depths of 6 are readily reached  which forces either a
> >presumption of an environmental dependency for a deeper stack,
> >or designing the functions to use scratch variables which introduce
> >other problems with the use of these functions.

> Greg suggests:
> >GB So, another way to handle (2) that would I think be consistent
> >with the way we address this same issue for the data stack would
> >be to delete the specification of any minimum at all.  In the
> >rationale we point out that as a practical matter systems had
> >better provide some way for an application programmer to *obtain*
> >whatever his application requires, and that this specifically
> >means that placing *either* stack in a hardware resource whose
> >size is architecturally bounded at some small limit will in turn
> >severely limit the range of Standard programs it may expect to
> >run.

> My observation:
> >EDR As to stack depth, we released SwiftForth with FP stack
> >in memory, and after a firestorm of protest from customers we
> >made hw/sw stacks a configuration option.  IMO it's a mistake
> >to _prevent_ customers from writing optimal code.  If we make
> >a large minimum stack depth, implementors will be constrained
> >from supporting hardware stacks.  I'd rather leave the burden
> >on the program to document the minimum stack depth it needs.

> I'm particularly interested in hearing from those of you supporting
> significant applications involving floating point, who might be
> most affected by these decisions.

> I'm especially interested in any information as to the prevalence
> of integrated fp stacks; several people have asserted confidently
> that "nobody" does it that way, and although I'm all for a separate
> fp stack, I suspect that there is a body of existing integrated-stack
> code out there that could cause trouble.

> Thanks,
> Elizabeth



Mon, 26 Nov 2001 03:00:00 GMT  
 Floating point in ANS Forth

[..]

Quote:
> Factorizing my math feels more like generating Cantor's Dust than solid code.
> Several of my algorithms have complex states, and I'd like to be able to allocate
> separate FP stacks for each of them.  Presently, I use large arrays for state and
> historical data (such as for adaptive moving window averages), and I wish I were able
> to use Forth stack operators on these data structures, instead of my own slow code
> for manual indexing and copying operations.  The only new words needed would be for
> copying between these allocated stacks, and would look alot like those for the D and R
> stacks, but with at least one additional stack parameter specifying the stack(s) involved.

[..]

I get the impression you're using the FP stack for a purpose it is not designed for (local
storage, like in arrays and matrices). Could you publish a few dust particles to solidify this?
Maybe there is a simpler way.

-marcel



Tue, 27 Nov 2001 03:00:00 GMT  
 Floating point in ANS Forth
With so many machines out there with 8 deep floating point stacks (ie
Intel boxes) it seems a shame (although understandable) to prevent
implimentations from using the hardware option when possible. I do
agree that serious FP apps require a deeper stack but in that case
just get a compiler that supports a software fp stack

Thomas Worthington

Zl svefg cbfgvat sebz Yvahk



Tue, 27 Nov 2001 03:00:00 GMT  
 Floating point in ANS Forth

[..]

Quote:
> 1) Discarding the entitlement for integrated fp/data stacks, and mandating a
> separate fp stack.
> 2) Enlarge the minimum fp stack size to 16 items.

[..]

Quote:
> Here's some of the discussion so far.  I'd appreciate comments from those of
> you that write a lot of fp code.
>> EDR  I'm happy to ditch the separate stack, but note that there are
>> a large number of users of URForth (LMI) with integrated stacks.
>> One of them was even talking about porting Ray's FP package to
>> SwiftForth to avoid rewriting his applications that assumed integrated
>> stacks (don't know if he actually did).  So there's potential for mad users.

I thought that portable code had to use FP in such a way that it could
run on both kind of systems. This seems to be really possible (quoth Ray
Duncan). I didn't know URForth was an ANS system, though.

[..]

Quote:
>> EDR As to stack depth, we released SwiftForth with FP stack
>> in memory, and after a firestorm of protest from customers we
>> made hw/sw stacks a configuration option.  IMO it's a mistake
>> to _prevent_ customers from writing optimal code.  If we make
>> a large minimum stack depth, implementors will be constrained
>> from supporting hardware stacks.  I'd rather leave the burden
>> on the program to document the minimum stack depth it needs.

`Unlimited stack' depth while still using the FP hardware stack (spill
to memory) is easily implemented for NC Forths. I've been using such
systems for at least 10 years. On none-NC Forths it won't be detectably
faster / slower. For user CODE words it doesn't matter. So in all cases
the Forth programmer benefits, the Forth vendor suffers.

Quote:
> I'm particularly interested in hearing from those of you supporting
> significant applications involving floating point, who might be
> most affected by these decisions.

For a start, bigFORTH is an ANS system, and its OpenGL and MINOS
implementations hardly count as minor efforts.

I think Mops also did use combined stacks, but it changed and nobody
complained.

Quote:
> I'm especially interested in any information as to the prevalence
> of integrated fp stacks; several people have asserted confidently
> that "nobody" does it that way, and although I'm all for a separate
> fp stack, I suspect that there is a body of existing integrated-stack
> code out there that could cause trouble.

Maybe small systems shouldn't want to upgrade. On larger systems: link
dynamically to the old code or retrofit the old system with some form
of IPC. This keeps everybody happy and we might get dynamic linking on
the agenda sooner :-)

In general I think serious high-performance codes will always be
(slightly) non-standard and their programmers hardly quibble standard
conformance issues.

-marcel



Tue, 27 Nov 2001 03:00:00 GMT  
 Floating point in ANS Forth


Quote:
> The ANS Forth TC is reviewing floating point requirements.  Skip Carter,
> head of the FSL effort, has recommended two things:

> 1) Discarding the entitlement for integrated fp/data stacks, and
mandating a
> separate fp stack.

> 2) Enlarge the minimum fp stack size to 16 items.

Elizabeth,

-Sorry about my bad english-

Quote:
> 1) Discarding the entitlement for integrated fp/data stacks, and
mandating a
> separate fp stack.

    2 problems appears in this case:

    1.  I have _more_ than 10000 lines of code that become incompatible
        (but OK: its my problem)

    2.  Having the same stack is convenient when passing floats from
        Forth to 'C'

Quote:
> 2) Enlarge the minimum fp stack size to 16 items.

    No sense:
        why not 32 items or more ?
        16 is too small when a word use a word that use a word that use ...

I have another proposition:
---------------------------

1)  "The minimum fp stack size is hardware dependant. A minimum of 6 items
is assumed."
    A program using the hardware stack is hardware dependant.

    A word using the hardware stack must empties the stack before exiting a
word.
    Hardware stack is used in critical sequence.
    In last issue, the hardware-stack can be emulated ...

2)  In standard mode, integrated fp stack is used!
    A float size must have the same size than a cell!
    In standard mode, the hardware stack can also be used. (critical
sequence)

    If a float size is greater than one cell, the integrated fp stack must
use
    an float-array and represent floats with relative-addresses.

    If a float size is equal than one cell, the math emulator can use
    directly the data stack: probably faster.

I think this system is more general: we can consider that most of actual
Forth-systems
uses an emulated hardware-stack.

Unknow systems (my system fall in this group) using integrated-fp become
"standard".

Sorry - its my opinion (today jun 11 - 22:40)

Sincerely
Charles Melice



Quote:
> The ANS Forth TC is reviewing floating point requirements.  Skip Carter,
> head of the FSL effort, has recommended two things:

> 1) Discarding the entitlement for integrated fp/data stacks, and
mandating a
> separate fp stack.

> 2) Enlarge the minimum fp stack size to 16 items.



Tue, 27 Nov 2001 03:00:00 GMT  
 Floating point in ANS Forth

[..]

Quote:
>> 1) Discarding the entitlement for integrated fp/data stacks, and mandating a
>> separate fp stack.
[..]
>    2.  Having the same stack is convenient when passing floats from
>        Forth to 'C'

But it breaks down when C returns results to Forth, and there are
completely different problems when calling fortran from Forth :-)

(I made remarks on issues like these in my previous reply to
 Elizabeth, but edited them out again because I think they're
 irrelevant at this point in time)

Quote:
>> 2) Enlarge the minimum fp stack size to 16 items.

>    No sense:
>        why not 32 items or more ?
>        16 is too small when a word use a word that use a word that use ...

This is based on FSL test experience. For some selected algorithms
the maximum stack depth has been monitored and documented.

It is easy to come up with contrived examples where 16 items is
not enough, but that is not a convincing way to define a minimum
entitlement.

Quote:
> I have another proposition:
> ---------------------------
> 1)  "The minimum fp stack size is hardware dependant. A minimum of 6 items is assumed."
>    A program using the hardware stack is hardware dependant.
>    A word using the hardware stack must empties the stack before exiting a word.
>    Hardware stack is used in critical sequence.
>    In last issue, the hardware-stack can be emulated ...

This is not possible and not useful. If the system were to use the hardware
stack with software spill to memory, how do you know the free entries your
own words can use? More important, if you don't use the stack to *pass
parameters*, (local) variables serve just as well as the stack.

Quote:
> 2)  In standard mode, integrated fp stack is used!
>    A float size must have the same size than a cell!
>    In standard mode, the hardware stack can also be used. (critical sequence)

It is simply unacceptable to limit a float to a CELL, at this point in time.
Some current systems are using 80-bit floats, and all OS and library routines
use 64-bits (WIN32 / Linux).

Quote:
>    If a float size is greater than one cell, the integrated fp stack must use
>    an float-array and represent floats with relative-addresses.

This looks like a good idea. It allows 32/64/80/any size floats. There is no
need for FDUP FSWAP FPICK FROLL ... It makes linking to FORTRAN very easy
(call by reference). However, linking to C is now a problem and, most
important, I think there will be serious readability problems. Of course,
this would have to be tested a lot before it can be standardized.

And, of course, I would refuse to use this scheme because it is very
inefficient ( == takes many months to optimize).

Quote:
>    If a float size is equal than one cell, the math emulator can use
>    directly the data stack: probably faster.


[..]

Quote:
> Sorry - its my opinion (today jun 11 - 22:40)

There is hope, then.

-marcel



Wed, 28 Nov 2001 03:00:00 GMT  
 Floating point in ANS Forth
"Elizabeth D Rather"  writes:

Quote:
> The ANS Forth TC is reviewing floating point requirements.  Skip Carter,
> head of the FSL effort, has recommended two things:

> 1) Discarding the entitlement for integrated fp/data stacks, and mandating a
> separate fp stack.

> 2) Enlarge the minimum fp stack size to 16 items.

        [ deleted ]

Regarding #1, while it may be true that it is possible to write
code that will work on either, I have not found it easy. For me
"easy" is to keep the stacks separate. I see no reason to change
that based on what others have said, for ex. to simplify linking
to libraries of code.  OTOH, I have no objection to using a unified
stack for people who prefer it that way, and see no reason to forbid
such. I do not believe the FSL code will be run often on machines
for which the latter is an issue, i.e. 8-bit processors with fp
emulation and small memory--but perhaps I am wrong.

I do  not see the need for a mandate in Re: fp stack depth, as long as

        a) the user can offload to memory if necessary from
           fpu hardware;

        b) an ANS FLOATING and FLOATING EXT wordset includes
           the necessary hooks to extend the fp stack.

In other words, I am not displeased by the status quo, and am not sure
we have yet run into enough problems to justify important changes.

--
Julian V. Noble

"Elegance is for tailors!"    -- Ludwig Boltzmann



Fri, 30 Nov 2001 03:00:00 GMT  
 Floating point in ANS Forth
Quote:

> The ANS Forth TC is reviewing floating point requirements.  Skip Carter,
> head of the FSL effort, has recommended two things:

> 1) Discarding the entitlement for integrated fp/data stacks, and mandating a
> separate fp stack.

> 2) Enlarge the minimum fp stack size to 16 items.

I have no {*filter*} feelings about either issue, but I'll throw in a
couple of comments:
1a)  I am glad I've never taken any time to get code that could
run on an integrated stack; I expect this state of grace to continue.
1b)  It should be pretty easy to write a tool to convert (where
necessary) code expecting an integrated stack to code using a
separate fp stack, and the result would generally be nicer.;-)
2a)  Given the comments of others, it's hard to imagine a strong
argument beyond laziness for opposing an increase of the minimum
size to 8 from 6.  More would be nice, but might cause someone
a little bit of effort, I suppose.

While I'm at it, a couple of mild wish-list items:
1)  A more explicit description in the Standard of the output
produced by F. , FE. , and FS. in conjunction with PRECISION.
This could be done, for example, by referring to corresponding
(preferably) Fortran or C formatting expressions.  (Of course,
as Marcel has mentioned elsewhere, additional custom words
will still be needed by many users.)
2)  A pair of standard words for moving the full internal
representation of a floating-point value from the floating
to the data stack (number of cells needed implementation dependent
of course) and back, for paralleling the use of the return
stack for temporary storage.  The purposes are at least as well
accomplished with fp local variables, but there is no standard
syntax for _them_; and often the need for a full fp-locals
implementation would be obviated.

just stray thoughts...   cgm



Sun, 02 Dec 2001 03:00:00 GMT  
 Floating point in ANS Forth

: The ANS Forth TC is reviewing floating point requirements.  Skip Carter,
: head of the FSL effort, has recommended two things:

: 1) Discarding the entitlement for integrated fp/data stacks, and mandating a
: separate fp stack.

: 2) Enlarge the minimum fp stack size to 16 items.

Oh dear!  This would substantially complicate things on the x86
architecture, and disallow simply using the hardware stack.  I
understand why some want 16 items, but it would cause considerable
problems.

The issue for me has always been the way that some floating-point
library routines use many stack items internally: if I remember
correctly, the worst offender was fp to string conversions, which used
almost the whole stack.  

Perhaps the best solution would be a portable way to unload the
floating-point state into some temporary area.

: My observation:
: >EDR As to stack depth, we released SwiftForth with FP stack
: >in memory, and after a firestorm of protest from customers we
: >made hw/sw stacks a configuration option.  IMO it's a mistake
: >to _prevent_ customers from writing optimal code.  If we make
: >a large minimum stack depth, implementors will be constrained
: >from supporting hardware stacks.  I'd rather leave the burden
: >on the program to document the minimum stack depth it needs.

Perfect.

Andrew.



Mon, 03 Dec 2001 03:00:00 GMT  
 Floating point in ANS Forth
"Charles G. Montgomery"  writes:

        [ deleted ]

Quote:
> While I'm at it, a couple of mild wish-list items:
> 1)  A more explicit description in the Standard of the output
> produced by F. , FE. , and FS. in conjunction with PRECISION.
> This could be done, for example, by referring to corresponding
> (preferably) Fortran or C formatting expressions.  (Of course,
> as Marcel has mentioned elsewhere, additional custom words
> will still be needed by many users.)
> 2)  A pair of standard words for moving the full internal
> representation of a floating-point value from the floating
> to the data stack (number of cells needed implementation dependent
> of course) and back, for paralleling the use of the return
> stack for temporary storage.  The purposes are at least as well
> accomplished with fp local variables, but there is no standard
> syntax for _them_; and often the need for a full fp-locals
> implementation would be obviated.

> just stray thoughts...   cgm

Definitely endorse #2. I haven't had any problems with F., FE., or
FS. That is,
****************************************************************
12.6.2.1427 F.
f-dot FLOATING EXT

        ( -- ) ( F: r -- )
        or ( r -- )

Display, with a trailing space, the top number on the floating-point stack using fixed-point notation:

        [-] <digits>.<digits0>

An ambiguous condition exists if the value of BASE is not (decimal) ten or if the character string representation exceeds
the size of the pictured numeric output string buffer.
****************************************************************

I understand this.

****************************************************************
12.6.2.1513 FE.
f-e-dot FLOATING EXT

        ( -- ) ( F: r -- )
        or ( r -- )

Display, with a trailing space, the top number on the floating-point stack using engineering notation, where the
significand is greater than or equal to 1.0 and less than 1000.0 and the decimal exponent is a multiple of three.

An ambiguous condition exists if the value of BASE is not (decimal) ten or if the character string representation exceeds
the size of the pictured numeric output string buffer.
****************************************************************

I understand this also.

****************************************************************
12.6.2.1613 FS.
f-s-dot FLOATING EXT

        ( -- ) ( F: r -- )
        or ( r -- )

Display, with a trailing space, the top number on the floating-point stack in scientific notation:

        <significand><exponent>

where:

        <significand>  :=  [-]<digit>.<digits0>
        <exponent>     :=  E[-]<digits>

An ambiguous condition exists if the value of BASE is not (decimal) ten or if the character string representation exceeds
the size of the pictured numeric output string buffer.
****************************************************************

And I even understand this. Is the ambiguity related to how many
figures are displayed overall? I would imagine that PRECISION defines
the total number of digits, before and after the decimal point.
If you are saying that this should be stated explicitly, I agree.

--
Julian V. Noble

"Elegance is for tailors!"    -- Ludwig Boltzmann



Mon, 03 Dec 2001 03:00:00 GMT  
 Floating point in ANS Forth

Quote:

>: >I'd rather leave the burden
>: >on the program to document the minimum stack depth it needs.
>Perfect.

For a program to document the stack depth it needs it must know
the stack depth needed by every standard word it uses.  If F>D
has intermediate steps that increase the stack depth, that's
important.  

So the minimum stack depth will vary from implementation to
implementation.  Given the maximum depth used by each standard
word in an implementation it would be possible to calculate the
depth needed for a program, in many cases.  It would surely be
possible to calculate the depth needed for a collection of
important routines.  It looks like a significant amount of work.

Maybe the documentation could be sparser than that, maybe what
you want is:

1.  This routine definitely requires more than eight FP stack items.

or

2.  This routine requires only N FP stack items provided that none
     of the standard words it uses require a greater depth than the
     max of their input or output depth.

or something else.



Mon, 03 Dec 2001 03:00:00 GMT  
 Floating point in ANS Forth

Quote:

>"Charles G. Montgomery"  writes:

> [ deleted ]

>> While I'm at it, a couple of mild wish-list items:
>> 1)  A more explicit description in the Standard of the output
>> produced by F. , FE. , and FS. in conjunction with PRECISION.

[..]

Quote:
>Definitely endorse #2. I haven't had any problems with F., FE., or
>FS. That is,
>Is the ambiguity related to how many
>figures are displayed overall? I would imagine that PRECISION defines
>the total number of digits, before and after the decimal point.
>If you are saying that this should be stated explicitly, I agree.

Well, I expect PRECISION to affect the number of digits after the
decimal point only.

What can happen with  0e F. ? Prints "0" or "0.0000000" or "00.0000"?
Should a plus sign be printed? How to get the output into a string?
How to get fixed width output? How to handle output that doesn't fit the format (3 SET-PRECISION
1.23283283273e12 F.)? Because this isn't defined,
you can't write scripts to test algorithmic output on different Forths (unless you rewrite all
formatting words with REPRESENT ).

FP number output is definitely the weakest spot of the whole wordset.
Somebody please invent pictured numeric output for FP :-)

-marcel



Mon, 03 Dec 2001 03:00:00 GMT  
 Floating point in ANS Forth

Quote:

>The issue for me has always been the way that some floating-point
>library routines use many stack items internally: if I remember
>correctly, the worst offender was fp to string conversions, which used
>almost the whole stack.

        Ouch!  There's no excuse for such laziness!  It's possible to only
use the one position occupied by the number being converted.  All
intermediate values can use either that one position or the integer stack.

-GJC



Mon, 03 Dec 2001 03:00:00 GMT  
 Floating point in ANS Forth

Quote:


>>The issue for me has always been the way that some floating-point
>>library routines use many stack items internally: if I remember
>>correctly, the worst offender was fp to string conversions, which used
>>almost the whole stack.
>        Ouch!  There's no excuse for such laziness!  It's possible to only
>use the one position occupied by the number being converted.  All
>intermediate values can use either that one position or the integer stack.

Can you divide by 10.0 without using a second position?  If you can do it
on Intel, can you also do it on any other coprocessor?

I think I remember an instruction to do it for you, and presumably that
instruction doesn't take any other positions.  But what about getting the
precision right?  I vaguely remember some complications there.



Tue, 04 Dec 2001 03:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. ans forth floating point

2. Why Separate Floating Point Stack in ANS Forth?

3. ANS Floating Point?

4. An alternative to floating point (was Re: Floating point non-exactness)

5. IBM 370 Floating point to IEEE floating point

6. ANS Forth in ANS Forth?

7. Floating point word set in Forth-83 ?

8. Emulating floating point in FORTH.

9. Floating Point Forth for the IBM

10. Floating point in Forth

11. Getting a floating point number from a float-object

12. vax floating pont to unix floating point

 

 
Powered by phpBB® Forum Software