home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.arch:10957 comp.lang.misc:3811
- Path: sparky!uunet!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
- 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)
- Message-ID: <TMB.92Nov20135549@arolla.idiap.ch>
- Date: 20 Nov 92 21:55:49 GMT
- References: <1992Nov13.200222.23955@sal.wisc.edu> <id.OS0V.0DI@ferranti.com>
- <TMB.92Nov17222432@arolla.idiap.ch> <id.MT2V.RXE@ferranti.com>
- Reply-To: tmb@idiap.ch
- Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
- Perceptive)
- Lines: 76
- 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.
-