🚀 go-pugleaf

In article <39609@think.UUCP>, barmar@think.COM (Barry Margolin) writes:
> In article <134@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes:
  
			......................

> The solution to this is to hide these instructions away in subroutine
> libraries and/or compiler intrinsics.  In addition to making it easy
> for the compiler to recognize these operations and optimize them
> appropriately, it also makes it easier to port the code and still get
> good performance.
> 
> This is how computer languages and processors evolve in general.
> Consider floating point and trigonometric functions.  Once upon a time
> programmers might have been required to code these things themselves.
> But this would make it difficult to use hardware which has these
> operations built in.  So just about every language provides them as
> standard features, with provisions for open-coding them.  What's the
> difference between operations on floating point numbers and operations
> on sophisticated data structures such as queues?

And suppose you want multiple precision.  In that case you need good 
coding AND GOOD INTEGER INSTRUCTIONS.  There are multiple precision
packages written in floating point.  They simulate integer arithmetic
in floating point, and are necessarily VERY slow.  Current hardware on
most machines throws real obstacles into efficient multiple precision
coding.  Slight differences in the multiplication and division instruc-
tions can cause a factor of 2-20 or more in these.

It is not true that all languages provide procedures for open coding.
Most provide some procedures for attempting to open-code, but most
implementations I have seen discourage this.  
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)