Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: Standard follies
Summary: so, how do we fix it?
Message-ID: <5571@pt.cs.cmu.edu>
Date: 19 Jul 89 05:56:51 GMT
References: <8907181614.AA06989@jade.berkeley.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 51

In article <8907181614.AA06989@jade.berkeley.edu>, wmb@SUN.COM writes:
>...
> What is needed is a an unsigned 0= operator!  On a 2's complement
> ...
> It irks me that it is *not possible* to write clean portable code in
> standard Forth (conditional compilation is not clean, in my book), due to
> too few operators, thus forcing the existing operators to do double
> duty and thus to have "surprise" implementation dependencies.

You still haven't explained which 1's complement machines are
about to flood the marketplace....

But, it appears that your argument is that Forth itself is broken.
Do you propose changing the language, or making implementations in
hardware and software bite the compatibility/speed loss bullet?

> > 3) Separate floating point stack -- too expensive
> > ...
> I think it's shortsighted to assume that the word size is going to
> stick at 32 bits.
> ...
> I think it's because the combinatorics of 16/32 integer size X single/
> double/extended floating point size makes people's brains hurt
> when they thing about the stack manipulations.

But, when basic integer sizes reach 64 bits, I think it likely
that "single precision" floating point will also go to 64 bits.
The number of bits itself isn't interesting.  What I'm speculating
is that we will reach a balance, where single-precision integers
and floats will be the same size, and that they will both increase
in size together.

> The purpose of a standard ought to be to allow the creation of
> portable programs.  Specific hardware doesn't have to directly implement
> the standard.  It can implement whatever the designer can sell.
> However, the software that runs on that hardware should implement
> the standard.  Providing additional features or faster modes is fine,
> so long as the standard semantics are also available.

So, it's OK to sell a very fast Forth with stack hardware, as
long as a compatibility mode with the standard (that does
floored division, and emulates a floating point stack in
program memory) is available?  If so, I agree with you.
What I'm arguing against is mandating significant inefficiencies
in the base package, so that the user is *stuck* with them.

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor.
I don't speak for them, and they don't speak for me.