GEnie@willett.UUCP (ForthNet articles from GEnie) (12/22/89)
Message 10 Thu Dec 21, 1989
R.BERKEY [Robert] at 04:43 PST
To: Roedy Green
rg> 7.1900 MOVE
rg> I gather that MOVE is a smart CMOVE that selects CMOVE
rg> or CMOVE>. This is unwise. 99% of the time the strings
rg> do not overlap. The checking overhead is wasted.
Have you seen a word-alignment-optimized CMOVE for the 8086 (not 8088)?
Getting the replication behavior is slightly less efficient than doing the
address test. Greg Bailey has reported hardware whose string-move primitive
is "smart". For these two systems, CMOVE is worse for both programmer and
system. CMOVE 's elegance is really only for 8-bit devices.
--------
In 1981 I strongly agreed that CMOVE and CMOVE> was the way. Now, the
additional programmer work involved in choosing between the two has been
eroded by time. I sense deep lessons here. Programmer's have rarely needed a
dumb CMOVE (it can be handy to initialize an array with an address). I think
a key may be to consider the number of concepts involved in a word. CMOVE has
two: "data movement" and "replication", whereas MOVE only has "data movement".
This is complexity on the human side of the programming problem. As evidence
of this complexity in the real-world, I've got a bug report on my desk right
now that reads, "If selection 2 were chosen, the number actually dialled would
be 16666666".
--------
Another principle I've seen repeatedly is that speed concepts in the Standard
cause problems, i.e, BUFFER is a word whose purpose is for speed, but since
speed can't be specified, implementors can define BUFFER as:
: BUFFER BLOCK ;
As a programmer, execution speed is an important and on-going consideration.
That doesn't mean that it translates well as a portable concept. It's a given
that absolute speed doesn't port. That leaves relative speed to consider.
My DIVREPLIES file contains an example of how problematic relative speed
analysis can be. Consider quantifying your comment that, "The checking
overhead is wasted". It's obvious enough at the cycle level, yet it might be
difficult to locate a real world case where those cycles add up to a
detectable amount of time and a real-world impact. (And compare this with the
time of the half-dozen people involved in the bug report on my desk.) And now
add to this the dimension of time: CMOVE is evidence enough that relative
speed is fickle across time.
My conclusion is that speed should be low on the list of tradeoffs for
choosing functions for a Standard.
--------
MOVE in some Forths means MOVE-WORDS. This reuse with
a different meaning is bound to cause confusion. Perhaps
we could call it COPY or REP (replicate). The word should
be short and fast since it is used so often.
Forth-79 had a MOVE that had a word count, but my impression and experience is
that it was rarely used. And the word-count definition was deprecated in 1982-
-the Forth-83 Uncontrolled Reference Word Set defines MOVE to be "smart".
Granted that with the committee introspecting over 1978 Forth, Inc. words,
that alone need not be a limitation. By the way, COPY is well established as
an operator to duplicate a block.
I agree that the standard's committees have a bias I've called "naming
jealously", the preference to "fix" an existing function rather than also add
to the task the problem of getting concensus on a new name. Like, I've
questioned the 1982 change to PICK . Yet, would it be better today if we were
using +PICK or PICKUP ? It's occasionally been a minor nuisance to me in
reading someone else's code. I'd be interested in your opinion.
------------
-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/06/90)
Category 10, Topic 31
Message 11 Sun Dec 24, 1989
R.BERKEY [Robert] at 09:10 PST
Roedy Green writes:
RG> 7.0540 >
RG> Specify that > must give the correct answer even when
RG> comparing max-minus and max-plus. In other words the
RG> compare must be implemented with compare instructions, not
RG> subtractions. If you don't want to do that, specify in the
RG> standard that comparisons involving max plus and max minus
RG> are undefined.
Interesting. Implementors of 32-bit systems can define the range of a signed
number as +-2^30, and implement > with a subtraction.
: > ( n1 n2 -- Flag ) SWAP - 0< ;
Relatedly, by declaring unsigned numbers at +2^30, one can then define:
: U> > ;
-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'