Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.arch
Subject: Re: bizarre instructions
Message-ID: <10278@dog.ee.lbl.gov>
Date: 25 Feb 91 23:20:18 GMT
References: <9102220245.AA14853@ucbvax.Berkeley.EDU> <1991Feb25.134714.23523@linus.mitre.org> <10244@dog.ee.lbl.gov> <1991Feb25.203629.5059@linus.mitre.org>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 89
X-Local-Date: Mon, 25 Feb 91 15:20:18 PST

[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'.]

In article <10244@dog.ee.lbl.gov> I demonstrate that the last claim
is false.

>>This has its drawbacks: the syntax is distinctly un-pretty, and it
>>requires gcc, and it is machine-dependent.  It does, however, work.

In article <1991Feb25.203629.5059@linus.mitre.org> bs@faron.mitre.org
(Robert D. Silverman) writes:
>Ah yes. A universal solution. Machine dependent. Ugly syntax. Only
>works with one compiler.

Do you want a machine-independent solution for using the machine
instruction(s) that compute(s) (A * B + C) divrem D?

This is clearly impossible, since some machines have no such instructions.


Do you want a machine-independent (but language-dependent) syntax for
expressing `(A * B + C) divrem D', and one which does not require a
subroutine call per operation?

This is what I provided.  If you believe you can improve on the syntax,
go to it; knock yourself out.  (Incidentally, the only reason it `only
works with one compiler' is that only one compiler compiles the
particular language GCC implements.  GCC is not a C compiler [well, it
is if you run it with `-ansi -pedantic'].  There is, however, no
constraint that says that GCC's language may not be adopted by other
compilers.)


I dare say you do not want a language-independent syntax, since `syntax'
and `language' are tightly-interwoven concepts.


Do you want machine-independent semantics, given some syntax, for
(A * B + C) divrem D?  I believe this not to be the case (since I
believe that you would prefer 64-bit A,B,C,D with 128-bit intermediate,
which I believe you believe is not available on many machines).


>Furthermore, it does nothing to contradict the assertions I made above
>that the arithmetic could not be done in the HLL and that assembler
>routines had to be called. It does inline the subroutine, however.

I have only a vague idea what `could not be done in the HLL' means.
Did I use a construct that is not provided by the compiler?  Or is
`assembler routines had to be called' the key phrase?  Do you mean
`machine dependent instructions had to be emitted'?  Of course this is
the case.  Do you mean `the rules for emitting the machine dependent
instructions were not built into the compiler'?  This depends on what
one means by `built in'.  Is the following sin() routine `built in'
to the compiler?:

	static __inline const double sin(double x) {
		double result;
		__asm("sin %1,%0" : "=f"(result) : "f"(x));
		return result;
	}

I claim that if this appears in <math.h>, it *is* built-in to the
compiler, despite the fact that the compiler reads these rules from an
external file rather than having them embedded directly in its
executable.  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'.

Or maybe this is not what you wanted?  What exactly was it you *did*
want?  I know what *I* would want: I would want a syntax I could use to
write mul_add_div_rem operations such that:

 - they were not `fragile' (i.e., could be inserted anywhere);
 - they could directly use machine instructions that implement the
   operation wherever such are available;
 - they did not impose extra overhead;

and this is exactly what I constructed.  Perhaps I could have done a
better job; but perhaps I would have spent more than an hour on it....
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov


Brought to you by Super Global Mega Corp .com