Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!charon!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: bizarre instructions
Message-ID: <3025@charon.cwi.nl>
Date: 26 Feb 91 02:25:39 GMT
References: <10244@dog.ee.lbl.gov> <1991Feb25.203629.5059@linus.mitre.org> <10278@dog.ee.lbl.gov>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 24

In article <10278@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
 > [Bob Silverman asks for a way to compute (A * B + C) divrem D and
 > claims that `Even on machines that support double length integer
 > multiplies, one cannot put the above operations into HLL' (because
 > the compiler cannot use 32x32=>64 bit operations) and that `one is
 > FORCED to call assembler routines to do this'.]
etc.  Bob Silverman complains about the solution; Chris Torek writes:

 >              I further claim that if you require an <mp.h> to exist and
 > to define a mul_add_div_rem operation, and make constructing a proper
 > <mp.h> part of `building the compiler' (just as constructing a proper
 > <math.h> and <string.h> and <stdlib.h> is already part of building any
 > hosted ANSI C compiler), that your mul_add_div_rem operation will be
 > `built in'.
And this is exactly what Bob Silverman wants (if I read his mind
correctly that is).  As it is now, every user has to write his own for
every platform he encounters (and I have written some 40 upto now,
though through the use of subroutine calls, not through inlining in gcc).
And that was also the complaint of Peter Montgomery who has proposed such
a thing for the Fortran standard, and it is not there.  The current state
of affairs is that it is not in the standard for most languages.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl


Brought to you by Super Global Mega Corp .com