Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: int x int -> long for * (or is it 32x32->64)
Keywords: arithmetic,arbitrary precision
Message-ID: <41425@mips.mips.COM>
Date: 11 Sep 90 23:37:25 GMT
References: <3755@osc.COM> <4513@taux01.nsc.com> <119244@linus.mitre.org> <6837.26e7ee92@vax1.tcd.ie> <119612@linus.mitre.org> <3977@bingvaxu.cc.binghamton.edu> <119733@linus.mitre.org> <3984@bingvaxu.cc.binghamton.edu>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 54

I'm confused about the following exchange:

In article <3984@bingvaxu.cc.binghamton.edu> vu0310@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (R. Kym Horsell) writes:
>In article <119733@linus.mitre.org> bs@gauss.UUCP (Robert D. Silverman) writes:
...
>>amount of it. Typically, only having 32 x 32 --> 32 slows down
>>multi-precision arithmetic by about a factor of 10. Not having it

>Well that ``factor of 10'', in my simple-minded way, sounded a bit
>too far off the mark (of course it only _asymptote_ to less than 3 for sure).
>So I ran my littul benchmark. The results for VAX 8750 and Sparc,
>using a variety of compilers and optimization levels are as
>follows:
....
>Admittedly there is a lost to be said for my lack of understanding
>of experimental design, but I think we fail to see an
>order of magnitude difference between benchmarks 1 & 2.

>The difference? Benchmark 2 performed all calculations using
>int x int -> int while benchmark 1 used both int x int -> int
>and long x long -> long.

>I reiterate -- since int x int -> long is not _logically
>required_ then you must argue it's benefit from an _economic_ 
>viewpoint rather than a convenience one. 

I'm confused.  Since some fairly strong results are being stated
(that Silverman is way off; anyone can be off, but on the other hand,
Silverman certainly knows this problem domain), it would help
to understand exactly what is being measured. In particular,
I'm confused becasue Silverman clearly wished for 32x32->64,
and the posted results talk about int x int -> int, long x long -> long.

Unless I completely misunderstand the posting, I can't find any
connection whatsoever between the measurements of an apparently portable
C program on these machines, and Silverman's clear statement of wishing for
32 x 32 -> 64 bit product for a 10X difference in his work, since:
	int & long are both 32-bit anyway
	C doesn't expect 64-bit from 32x32; I don't know how, in C, you
		select between 32x32->32, and 32x32 -> 64,if both are
		actually available?  Are there C compilers that give this
		choice? (Note: MIPS has 32x32->64,
			but C just uses the low-order 32 bits)
	Existing SPARC implementations don't HAVE multiply instructions at all
		(other than multiply-step)

How about posting the benchmark, so we can understand what's happening?
It might especially be good to post a sample of the dissassembled code that's
supposed to be doing 32x32->64, if that is truly supposed to be happening.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086