🚀 go-pugleaf

In article <martin.721995695@bert> martin@math.rwth-aachen.de (  Martin Schoenert) writes:

   Thomas Breuel continues:

       (3) Many programming languages let you declare 32 and 64bit
	   integers explicitly and good compilers will select the right
	   instruction to go with the types (Ada and CommonLisp are
	   among those languages).

	   Even the C language has provisions for just the case that you are
	   concerned with in the case of 16bit integers, 32bit longs:

	       int a = ...;
	       int b = ...;
	       int c = ...;
	       long product = (long)a*(long)b;    [note correction]
	       int result = product/c;

	   In fact, on some machines, int is 32bit and long is 64bit,
	   so this code will do what you want.

   Ahh, but the 16x16->32 bit multiplication is not as good.  Suppose that I
   want to multiply two large integers, each 32 bytes long.  Using 16x16->32
   bit multiplication I  need 256 such  instructions.

You are missing the point. The above paradigm was created when
machines had 16bit integers and 32bit longs, and it worked pretty well
back then.

   Thomas Breuel continues:

	   Furthermore, C is being extended to allow access to 64bit types,
	   so that you can write:

	       int a = ...;
	       int b = ...;
	       long long product = (long long)a*(long long)b; [note correction]
	       int result = product/c;

   This  may  be  so,  but it  isn't  really  relevant.   Bob  talked  about
   *languages*,  you  talk about  *implementation* or  possible *extension*.
   This is not the same thing.

It is quite relevant. Now that machines have 32bit integers and 64bit
arithmetic as well, languages need to adapt.

Because integer sizes are machine specific, code that makes
assumptions about it is not going to be both portable and efficient.
To illustrate this, assume that C let you specify the size of integers.
Then, you could write:

	int:32 a,b,c;
	int:64 product = (int:64)a*(int:64)b;

That's fine, but will be rather inefficient on a 60bit machine with
30bit halfwords.

If anything, if you are going for efficiency, the C approach is more
portable, saying that "int" is whatever is fastest and "long" gives
you extra bits. "int" essentially used to mean "CPU register size" and
"long" was largely intended to mean "probably twice CPU registers
size, which coincidentally is what multiply may give you, unless
that's too inconvenient". The only problem with this approach was
that the early C compilers for 32bit machines messed up and didn't
make "long" 64bits.

So again, the problem of having machine independent access to machine
specific features hasn't been solved because it's inherently not
solvable. With somewhat better conventions, however, we might be able
to do a little better than we are doing now.

					Thomas.