Re: Announcement: Axiom, a Forth Based Universal Game Programming System

dreamwafer@xxxxxxxxx wrote:
On Aug 28, 2:05 pm, m...@xxxxxx (Marcel Hendrix) wrote:
dreamwa...@xxxxxxxxx writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System

On Aug 27, 11:41 pm, m...@xxxxxx (Marcel Hendrix) wrote:
Is less stack juggling not compelling enough?

Yes it is. I just wanted to make sure I wasn't overlooking other
important points
surrounding the issue.

Source code clarity: with a unified stack, you are never completely sure
that there is not a float involved somewhere, whereas with a separate
stack you simply write
: x ( adam bertha -- xantippe ) ( F: r -- cos{r} ) ... ;

Then there is efficiency: a separate stack works much faster when you
use the hardware FPU or SSE2 unit. Most fast Forths use a separate
FP stack, so your code can never be directly used on/ported to/checked
through them.

With a separate FP stack you switch to double or quad precision without
rewriting any code. (Say you want your Fractal generator upgraded to
256 bits with Julian Noble's ideas.)

-marcel

I see, I'll consider these points as well, thanks!

-- Greg


While all of the above arguments in favor of a separate fp stack have some
validity, collectively they may give the impression that Forth code written for
a unified/shared stack is hard to write, hard to document, and sluggish. Such a
conclusion should be met with skepticism. Some of the earliest Forth systems,
e.g. the LMI Forths featured a unified stack, and they were quite successful in
their day. I have worked extensively with a shared stack system, and even ported
a good bit of common Forth code to such a system:

http://ccreweb.org/software/kforth/kforth4.html

It may be that a separate stack system is now more compelling, given that it is
the common practice. However, should you decide to continue with a shared stack
system, I urge you to consider making fp numbers be double floats which occupy
two stack cells, rather than 32-bit fp numbers. Although it seems unlikely, and
the situation may never arise in your application, I have run into limitations
with the precision of 32-bit floats. Originally, in the days of DOS, I used
32-bit floats in an application named xyplot, to conserve memory. Now, I
actually have data which I cannot plot with this program, because the number of
significant digits is insufficient. This limitation is forcing a rewrite of a
good-sized program.

Krishna Myneni
.

Relevant Pages

  • Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator
    ... > based on reading the source that this driver uses "TCP port stealing" ... but using a separate MAC and IP opens up a bunch of other ... I don't think the right answer for iSCSI offload ... the stack would have to be ...
    (Linux-Kernel)
  • Re: New version of John Hayes tester
    ... It does not work as expected if the stack is non-empty before the {. ... It does not check FP results if the system has a separate FP stack. ... I have revised it to address both shortcomings. ... in the proposed Locals syntax. ...
    (comp.lang.forth)
  • Re: Named stack items
    ... > done by the compiler when the code is developed. ... > separate step during which optimizing can be done. ... limited scope compiler targetting a stack machine. ... or some other optimization point of your choosing. ...
    (comp.lang.forth)
  • Re: New version of John Hayes tester
    ... test suites. ... It does not work as expected if the stack is non-empty before the {. ... It does not check FP results if the system has a separate FP stack. ... I have revised it to address both shortcomings. ...
    (comp.lang.forth)
  • CfV: Separate FP Stack
    ... Writing floating-point code such that it can run on a unified stack is such a ... The floating-point stack is separate from the data stack. ... Kforth implements a subset of ANS Forth ...
    (comp.lang.forth)