🚀 go-pugleaf

In article <1992Nov22.192342.10288@qb.rhein-main.de> vhs@rhein-main.de writes:
>In article <1efg1gINNm6c@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
>> akao@.com (Adam Kao) writes:
>> : In article <Bxv2t2.4FH@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman  
>Rubin) writes:

			....................

>In the very moment you get hardware dependent you also lose portability. If
>you accept loss in portability, do it in assembler. If you need a portable
>assembler with elementary type-conversion and safe subroutine calls, symbolic
>names for variables and little overhead, use C. That's about as close to
>assembler (as hardware dependent) as you can get without resorting to assembler.
>I also can hardly imagine what a language would look like that had some special
>operators for e.g. "FP division by integer value with remainder saved" on one
>architecture but would compile and run on another one.
>Other than #define-ing some assembler macros for each machine and inlining the
>expansions.

We do not have full portability now, nor is it likely we ever will.  If 
word lengths change, or rounding changes, or whatever, portability is 
lost.  It is not necessary to lose all portability to get great improvement.

C is an atrocity as a portable assembler.  Too many of the instructions are
missing.  Such simple things as packing and unpacking, n x n -> 2n products
and the corresponding quotients, handling of overflows, bit operations,
and many others vary from non-existent to dead slow if you can do them.

This carries over to architecture.  Finding the next one in a bit stream
costs an arm and a leg in C, or even in machine language on most machines. 
Think of how much information must be considered; the number of bits left
in the current word being looked at, and of course what they are, the address
of the next word in the stream, and also that of the end of the stream.  Even
if all of these are in registers, it is not cheap, and we have 4 registers,
plus the output register, involved in this very simple operation, and we
have conditional code all down the line.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)