From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 20 Nov 92 21:55:49 GMT
	<TMB.92Nov17222432@arolla.idiap.ch> <id.MT2V.RXE@ferranti.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: peter@ferranti.com's message of Wed, 18 Nov 1992 20:09:18 GMT

In article <id.MT2V.RXE@ferranti.com> peter@ferranti.com (peter da silva) writes:

   In article <TMB.92Nov17222432@arolla.idiap.ch> tmb@idiap.ch writes:
   > I somehow don't follow your reasoning. If _some_ FORTH implementations
   > provide a particular machine specific feature, then it's "in the
   > language",

   The 16*16/16 operation, "*/", is in the language definition. All Forth
   implementations I ever used, back when I was using Forth extensively,
   provided this operator.

   I haven't used a 32-bit Forth, but I would consider any implementation
   that did not promote ALL the 16-bit operations incompetant.

So, is there a "32*32/32" operation in the FORTH standard? A
"64*64/64" operation? A "128*128/128" operation?

These are machine and implementation specific features, and different
languages provide access to them in different ways. On most 16bit
machines, the C paradigm (*) works quite admirably, just like the
FORTH paradigm does. On most 32bit (or 64bit or...), neither language
has a standard paradigm for expressing this.

(*)	int x=...,y=...;
	long product=x*(long)y;
	int result = product/z;

Certainly the original intent of the C language seems to have been
that (*) should continue to work (translating automatically into what
you call "32*32/32"). Hence, had it not been for the (maybe
unfortunate) decision to make "long" 32bits on 32bit workstation, C
would actually be somewhat more portable in its support of the idea of
word*word->double_word instructions.

For more concrete and portable support, I'd suggest standardizing the
interface to an implementation-dependent include file like the
following:

  /* 32bit workstation/compiler with 64bit "long long". */

  #ifdef __GCC__
  typedef int big_product_arg;
  #define bits_int_big_product_arg 32
  typedef long long big_product_result;
  #define bits_in_big_product_result 64
  #define BIG_MULTIPLY(x,y) ((big_product_result)(x)*(big_product_result)(y))
  #endif

  /* 32bit workstation/compiler without "long long". Note that this is less
     efficient than what the machine might provide. At fault is the absence of a
     64bit type to hold the result of the multiplication. */

  #ifdef __SUNC__
  typedef int big_product_arg;
  #define bits_int_big_product_arg 16
  typedef long big_product_result;
  #define bits_in_big_product_result 32
  #define BIG_MULTIPLY(x,y) ((big_product_result)(x)*(big_product_result)(y))
  #endif

  /* 16bit machine with 32bit long. */

  #ifdef __PDP11__
  typedef int big_product_arg;
  #define bits_int_big_product_arg 16
  typedef long big_product_result;
  #define bits_in_big_product_result 32
  #define BIG_MULTIPLY(x,y) ((big_product_result)(x)*(big_product_result)(y))
  #endif

You can first standardize this for yourself, then share it with other
people that are trying to solve similar problems to what you are
doing, and finally, if it turns out to be useful, this may become
supported by compiler vendors.

				Thomas.
Newsgroups: comp.arch,comp.lang.misc