HDTenEightyP/NetNews huggingface dataset:
From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: integer distance or sqrt
Organization: Software Engineering Institute
Date: Mon, 16 Nov 1992 17:26:04 GMT

In article <1992Nov16.110102.17077@imada.ou.dk> breese@monet.imada.ou.dk (Bjoern Reese) writes:

>Heron(x)   {Fast integer squareroot routine}
>   IF x <= 64 THEN
>      y = 2 + (x >> 3)  {shift right 3 times}
>   ELSE
    ...
>   ENDIF
>   root := (y + x DIV y) >> 1
>
>This algorithm is faster than Newton's Method...

Maybe so, but Newton's method doesn't tell you that the square
root of 0 is 1.
Xref: sparky comp.arch:10751 comp.lang.misc:3693
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: 15 Nov 92 21:30:27
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1992Nov12.131856.12605@linus.mitre.org>
	<TMB.92Nov13144057@arolla.idiap.ch>
	<1992Nov13.155126.3660@linus.mitre.org>
	<TMB.92Nov14145619@pollux.idiap.ch>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: tmb@pollux.idiap.ch's message of 14 Nov 92 14:56:19

In article <TMB.92Nov14145619@pollux.idiap.ch> tmb@pollux.idiap.ch (Thomas M. Breuel) writes:

       Even the C language has provisions for just the case that you are
       concerned with in the case of 16bit integers, 32bit longs:

	   int a = ...;
	   int b = ...;
	   int c = ...;
	   long product = a*b;
	   int result = product/c;

       In fact, on some machines, int is 32bit and long is 64bit,
       so this code will do what you want.

       Furthermore, C is being extended to allow access to 64bit types,
       so that you can write:

	   int a = ...;
	   int b = ...;
	   long long product = a*b;
	   int result = product/c;

Oops, that should, of course have been:

   long product = (long)a*(long)b;

and

   long long product = (long long)a*(long long)b;

Now, _my_ pet peeve with C is that this bug would have gone
undetected... (a compiler should warn about the lack of a conversion,
and a runtime system should catch any overflow).

					Thomas.
From: dresselh@rft30.nas.nasa.gov (Eliot Dresselhaus)
Subject: DEC Alpha performance; whose compiler?
Organization: Columbia U.
Date: Mon, 16 Nov 92 20:45:59 GMT

Who did the Alpha compiler correponding to the released SPECS?
Someone (DEC folks?) care to measure GCC-2.3's Alpha versus HP-PA SPECs?

-- 
- eliot
  dresselh@rft30.nas.nasa.gov		Internet
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Newsgroups: comp.arch
Subject: Re: PA-RISC ``semantic loading'' (according to DEC)
Date: 16 Nov 92 07:44:36 GMT
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group


--
In article <1992Nov13.173228.16970@odin.diku.dk>, thorinn@diku.dk
(Lars Henrik Mathiesen) writes:

> I suspect
> that PA-RISC can get by with executing fewer instructions as well.

This is, in a nutshell, the CISC viewpoint.

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97, FAX +33 92.95.52.00
Newsgroups: comp.arch,comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Purdue University Statistics Department
Date: Tue, 17 Nov 1992 13:00:37 GMT

In article <id.6S0V.FKH@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <Bxpoy9.GD6@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
>> There is jargon and there is jargon.  I know of no case in which anybody
>> in mathematics or statistics deliberately introduced jargon for the purpose
>> of obfuscation, or deliberately introduced notation which conflicted with
>> notation in another field.

>So you're making the claim that computer language syntax was deliberately
>introduced to obfuscate or conflict with another field? Is that really
>what you mean here, or am I putting words in your mouth?

I have given examples.  Some have even introduced conflicts with previous
notation in the computer field.  A brief repetition of some of them is in
order.

	The use of | for or.  The vertical bar has been used in mathematics
	for other things for years.  I suspect that if it were available
	when Fortran was developed, it would have been used for absolute
	value.  The notation of .OR. for it in some versions of Fortran
	was far better.  I do not remember who posted on the history of
	the added symbols in ASCII, but he did say that \ preceded |, so
	that \/ would have been available, corresponding to standard 
	mathematical notation.  Also, while it is more recent, the use
	of \ instead of &~ was already standard.

	The use of ^ for exclusive or.  Similar arguments apply.

	The obfuscation created by using * for indirection, expecially as
	there was, at least for users of English, an appropriate direct
	alternative @.  Similarly for ++ and --.  Also, using & for 
	"address of", which apparently does not give problems, really
	does.  This one is not so clear.

	Even the use of ; as a statement end conflicts with mathematical
	notation almost two centuries old.  The standard hypergeometric
	function is written as F(a,b;c;z), and this was extended to 
	versions with more arguments in the 19th century.

SOME of this may have been inadvertent, and due to the ignorance of those
introducing the notation.  But for a language designer with large backing
not to check on this is in the nature of criminal negligeance, at least.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
From: nevin@apple.com (Nevin ":-]" Liber)
Newsgroups: comp.arch
Subject: Re: A challenge to the anti-goto (C code included!)
Date: 17 Nov 92 08:08:54 GMT
Followup-To: comp.arch,comp.lang.misc
Organization: Apple Computer, Inc.

In article <1992Nov5.203759.8030@linus.mitre.org>, bs@gauss.mitre.org
(Robert D. Silverman) wrote:
> Dr. Rubin's main rule is:

> "The code should run as fast as possible"

> For him, all other considerations are secondary. Who are you to tell
> him what his priorities should be?

Because that isn't what he is asking for.  His model of efficiency totally
ignores OS overhead (eg page sizes, working set sizes, etc.), for instance.
 I've also never seen him deal with instruction or data caches or
pipelining.  All of which is extremely important if you need to do the
micro-optimisations that Herman always talks about.

> There are times when readability, portability, and ease of maintenance are
> of primary importance. There are times when they don't matter at all.

Only when the results don't matter at all.
___
NEVIN ":-)" LIBER, RISC Porting Specialist/Blue Meanie, Mac System Software
 email:     nevin@apple.com        paper:  Apple Computer, Inc.
 voice:     (408) 974-MIX1                 20525 Mariani Avenue, MS: 81-GC
 AppleLink: BADENOV                        Cupertino, CA 95014
Newsgroups: comp.arch,comp.lang.misc
From: akao@.com (Adam Kao)
Subject: Re: Hardware Support for Numeric Algorithms
Followup-To: comp.lang.misc
Organization: Oracle Corporation, Redwood Shores, CA
Date: Thu, 19 Nov 1992 21:25:46 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <1efg1gINNm6c@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
	[elided]

Your post raises many, many issues, which I simply cannot address without
losing the focus of the discussion.  When I say:

>:Computer science is related to mathematics only by
>: historical accident.

And you respond: 

>Yup, those mere "accidents of history", like Turing and Von Neumann.

I fear the discussion is becoming irrational.  I am sorry if my
statement offends you.  I am trying to express my opinions about the
history of computer science and its future direction.  It is an
obscure statement, but it is not meant to be insulting.

The fundamental motivation for my previous post was to address Herman
Rubin's charge of "criminal negligence".  My one and only point, then
and now, is that Herman Rubin has _no_ _right_ to charge computer
science with "criminal negligence".  He ASSUMES computer science has
only one responsibility, to mathematics (his mathematics) and
therefore, neglecting that responsibility is "criminal negligence".

This statement is unacceptable.  We cannot have a reasonable discussion
if you assume our wishes are subordinate to yours.  This is why we react
insultingly, and overreact, because you are STANDING ON OUR TURF and we
want you to BACK OFF.

You see only our overreaction, without understanding the cause, and it
creates the frustration you expressed in your post.  So you overreact back.

Once again.  If you call us "criminally negligent" we will feel insulted.
When we feel insulted, we will be uncooperative.  When we are uncooperative,
you will get frustrated.  When you get frustrated, you will talk LOUDER.

Is that clear?  Do you understand this vicious circle?  Do you understand
how to make it _stop_?


Adam

Xref: sparky comp.arch:10793 comp.benchmarks:1706
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch,comp.benchmarks
Subject: Re: Lisp performance (on Sparc SS2, SS10-30, HP720)
Date: 16 Nov 92 18:44:51 GMT
Followup-To: comp.arch
Organization: Auspex Systems, Santa Clara

>From the SpecInt92 results, one should expect a performance increase
>of about a factor of 2 when switching from a SS2 to either s SS10-30
>or HP720. Unfortunately, on both machines turned out to but just
>30% faster than a SS2 when running our system (for which ps NEVER
>shows a resident set under 3-4 MB, not even on an 8MB machine).

Just out of curiosity, does the HP machine have a write-through or a
write-back cache?  I've seen some cases where cache-buster programs
run better on machines with a write-through cache than on machines with
a write-back cache; your LISP interpreter+application may be such a
program.  The SS2 has a write-through cache, and the SS10 has, I think, a
write-back data cache.  (The SS10-30's caches are, when combined,
smaller than the SS2's cache - 20K Icache + 16K Dcache, vs. 64K combined
cache; how large is the HP's cache?)
Newsgroups: comp.arch
From: gglass07@ursa.calvin.edu (Gideon Glass)
Subject: SPARC user trap code available?
Organization: Calvin College
Date: Sun, 22 Nov 1992 08:03:50 GMT

I'm trying to figure out how to implement my own traps in SPARC
assembly (Sun IPCs/Sparc2's/SunOS 4.1.2 if it matters).  I've got the
architecture manual (verson 8) but I could really use some actual code
if anybody out there has any they'd like to share.  Anything at all
would be great.  Email to gglass07@calvin.edu, or else a point to an
FTP site if any exist with this sort of stuff on it.

Thanks in advance,
Gideon Glass

--
Gideon Glass              </-=({[||]})=-\>          gglass07@calvin.edu	
  "The experiments of Skinner and other operant researchers did far  
         more than teach us how to pull habits out of a rat."
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Newsgroups: comp.arch
Subject: Re: MINIMUM instruction set
Date: 15 Nov 92 13:41:00 GMT
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]

Scott Dorsey (kludge@grissom.larc.nasa.gov) wrote:
: 
: It's possible to build a machine with a single instruction (subtract and
: skip if equal), but definitely not practical.  I believe a student at U.
                      ^^^^^^^^^^
YOu can't say that. Based on my current thinking this is the future of a new
class of SUPER INTELLIGENT machines, that cannot crash. After all , there is
only one instruction(conditional).
	I've a strange feeling this is the way our mind works. 
--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet
Newsgroups: comp.arch
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Subject: Re: DEC Alpha AXP System Performance
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group
Date: Wed, 18 Nov 1992 04:58:40 GMT


--
In article <1992Nov16.120955.8904@qb.rhein-main.de>, vhs@rhein-main.de
(Volker Herminghaus-Shirai) writes:

> But at 220 Volts vs. 110 in the US, we can execute two instructions
> simultaneously ;-)

I'm afraid it doesn't quite work out this way.  European voltage is
double American voltage, but since AC is only 50Hz vs 60Hz in
the USA, the speedup is to only 1.67 instructions simultaneously.

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97, FAX +33 92.95.52.00
From: ulrich@weissnics.Germany.Sun.COM (Ulrich Graef SUN Frankfurt TSE)
Newsgroups: comp.arch
Subject: Re: integer distance or sqrt
Date: 20 Nov 92 17:53:43 GMT
Reply-To: ulrich@weissnics.Germany.Sun.COM
Organization: Sun Microsystems

If you are able to spend some memory, you can improve the processing very much.


First Method:	There are only 2^16  square roots of a number, which is 32 Bits long.
		So generate a table of the squares of the numbers from
			 2		    2
			0   ... ( 2^16 - 1 )
		and find the square root with a binary search. You need only
		1 comparison, 1 addition, 1 shift and 1 assignment per search step.
		If you unroll the loop, you do not need any loop overhead.
		Disadvantage: the table consumes 256 KB.

		You can also use the same table to square your dx and dy, if
		your multiplication is slower than a table lookup.


Second Method:	Use Newton, but find the first approximation with a table lookup.
				
		Variant a:	Use a table of the square roots of  0 .. 255 (* 2^24)
				Perform the lookup with the first byte.
				You need 2 additional iterations with Newton.
				The table consumes 1 KB.

		Variant b:	Use a table of the square roots of 0 .. (2^16-1)
								             (* 2^16)
				Perform the lookup with teh first two bytes.
				You need 1  Newton iteration (onle`y 1 division!).
				Disadvantage: the table consumes 256 KB.

I think,  if you spend enwough memory (you have no PC?) you can calculate the
distance very fast with the second method, variant b!

Uli
 		
Newsgroups: comp.arch
From: jg@crl.dec.com (Jim Gettys)
Subject: Re: Alpha
Organization: DEC Cambridge Research Lab
Date: Sun, 22 Nov 1992 15:53:21 GMT

In article <DERAADT.92Nov22043612@newt.newt.cuc.ab.ca>, deraadt@newt.cuc.ab.ca (Theo de Raadt) writes:
> Has anyone compiled any statistics on the origin of postings in comp.arch
> of late?
> 
> I'd be very interested to see how many postings have been coming from DEC.
>  <tdr.

Excluding this mail message, 49 of the last 825 messages (last two weeks,
I would guess) were from Digital, according to the news indexing tool 
I use here.  Given products based on Alpha were announced in the last 
two weeks I don't think this is all that remarkable; not all were on Alpha.
	Dileep Bhandarkar - 15
	Bob Supnik 	- 7
	Andy Payne 	- 4
	John Haxby 	- 4
	Pete Kaiser	- 3
	Pettengil (mulp)- 2
	Steve Dipirro 	- 2
	Jim Gettys 	- 2
	Ken Lee	   	- 2
	Richard Sharpe 	- 2
	Blair Phillips 	- 2
	Charlie Cassidy	- 2
	Wilson Snyder 	- 1

			- Jim Gettys
-- 
Digital Equipment Corporation
Cambridge Research Laboratory
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC Alpha architecture issues
Organization: Digital Equipment Corporation
Date: 23 NOV 92 13:04:41    


>In article <DOCONNOR.92Nov20095251@potato.sedona.intel.com> doconnor@sedona.intel.com (Dennis O'Connor) writes:
>>
>>Sounds like a microcoded instruction to me. Except, of course, that
>>there's no guarantee of what PALcodes are available on a particular
>>system, and that the microcode may be external to the chip.
> 
We first used this idea in 1985 in the PRISM architecture as epicode. The intent
was to implement complex functions (that used to be microcoded on VAX) within
a RISC architecture. It is like a microcoded instruction, except that it is
implemented in macrocode that runs in a special mode.

Dileep
Newsgroups: comp.arch
From: shyamal@seas.smu.edu (Shyamal Prasad)
Subject: Re: What happened to the UCSD p-System?
Organization: SMU School Of Engineering and Applied Science
Date: Wed, 18 Nov 1992 22:52:42 GMT

In article <1992Nov17.162428.15881@coe.montana.edu> uesu03@giac1.oscs.montana.edu (Lou Glassy) writes:
>Is the idea of running code on virtual machines dead?
>Found a couple of old books yesterday on the p-System and 
>MINT.  
>
>The possibility of taking my binary from machine to machine,
>(with possibly different physical architectures), and having
>it run without dinking, is an intriguing one.
>
>Is any work going on in this area?  Or does performance pay
>more than portability?
>

Just a passing comment - in these days when microcode is supposed to
slow a machine down would anyone interpret p-code as the major
execution mode ?

-- 
Shyamal Prasad, Department of Computer Science
Southern Methodist University, Dallas TX 72275
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.arch
Subject: 64-bit file sizes (was More Alpha AXP Performance Numbers)
Date: 19 Nov 1992 18:32:14 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

(N.B.: this has little relevance to comp.arch.  Followups should probably
be directed elsewhere, not that there should really be any followups.)

In article <1992Nov17.041026.27756@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg
(Othman Ahmad) writes:
>... With current 32-bit BSD unix, it can only access 2Gbyte addresses.

Current BSD Unix (4.4BSD-alpha) has 64-bit sizes.  There are still
some internal limits from 32-bit `block' numbers, but the external
interface provides signed 64-bit offsets.

>Must be a 64-bit version of Unix or VMS. Will it cause problems in
>porting software to apha?

From experience, yes.  The breakage is easy to fix once detected, but
does occur.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: pjd@cocamrd.mel.cocam.oz.au (Pat Dooley)
Newsgroups: comp.arch
Subject: Re: 64 bit Alpha AXP -vs- 32 bit computers
Date: 19 Nov 92 23:54:22 GMT
Organization: Co-Cam Computer Group, Oz

In article <1992Nov17.162014.6506@chpc.utexas.edu> kneuper@chpc.utexas.edu (Stephen Kneuper) writes:
>A debate is occuring at my site (and within my mind) regarding 64 bit
>versus 32 bit computing.
>
>I'm trying to figure out why I want to go to a 64 bit machine Alpha
>AXP system instead of continuing to run 32 bit machines (RS6K, Sun).
>
>Outside of the numerical analysis issues, the only other issues I see
>are:
>
>1.  64 bit ints allow the easy support of files larger than 2 Gbytes.
>
>2.  64 bit ints allow the construction of filesystems larger than 2
>Gbytes.
>
>I do know some vendors (convex) have addressed these issues within a
>32 bit architecture; Sun allows >2GB filesystems, if memory serves.
>Have I missed any other obvious (or not!) programming or system
>administration issues?
>
>-- 
>Steve Kneuper                                kneuper@chpc.utexas.edu - Internet
>Sr. Operating Systems Specialist
>University of Texas System (mailcode 78700)  kneuper@uthermes - BITNET
>Center for High Performance Computing        (512)471-2472

Commercial computing is moving beyond structured data. Database
systems holding BLOBS, such as images, voice, video clips, 
need much more that 2GB file systems. We already have problems
with databases hitting 2GB file limits even before we start
storing unstructured data.

You don't need a 64-bit machine to support a 64-bit file system,
but it helps. Remember the days when we had to program around 
16-bit limitations. Well, those days will return in the 1990s
as we program around 32-bit limits and lash together 32-bit
segments to stretch out address spaces past 4GB.

A 64-bit architecture should be real good for CHESS programs.
The whole board can be represented using 64 words or less. A
few ands, ors and xors and you can generate the set of possible
moves from a particular position.

64-bits should also be good for financial applications. No need
for micro-coded or milli-coded packed decimal to manipulate
dollar amounts.

Need 64-bits today? Probably not. Need them by 1995 to run 1995
applications? Quite likely. Need a 64-bit PC? Probably by 2001
if you want VR, Voice Recognition, Fully digital Video, etc. etc.

I'm sure other people can up with lots of useful ways to exploit
64-bit address spaces and the speed of single cycle 64-bit
integer and logical operations.
Newsgroups: comp.arch,comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Xenix Support, FICC
Date: Mon, 16 Nov 1992 21:37:57 GMT

In article <Bxpoy9.GD6@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
> There is jargon and there is jargon.  I know of no case in which anybody
> in mathematics or statistics deliberately introduced jargon for the purpose
> of obfuscation, or deliberately introduced notation which conflicted with
> notation in another field.

So you're making the claim that computer language syntax was deliberately
introduced to obfuscate or conflict with another field? Is that really
what you mean here, or am I putting words in your mouth?
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Newsgroups: comp.arch,comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Xenix Support, FICC
Date: Wed, 18 Nov 1992 20:09:18 GMT

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.
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Newsgroups: comp.arch
From: pfk@rz.uni-jena.de (Frank Klemm)
Subject: Re: integer distance or sqrt
Reply-To: pfk@rz.uni-jena.de (Frank Klemm)
Organization: Friedrich-Schiller-University Jena, Germany
Date: Tue, 17 Nov 1992 17:18:15 GMT


In article <CLIFFC.92Nov15184340@miranda.rice.edu>, cliffc@rice.edu (Cliff Click) writes:
|> bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
|> > because of the interest in Herman Rubin's optimization problems
|> > some people here might be interested in this.
|> > It is a real problem.  That is, I have a program that spends quite a 
|> > lot of time here, and I would like to change this if I could.  
|> 
|> > I first considered asking for a integer sqrt, but maybe if the context is 
|> > known a better answer can be given.  This program is normally run on a 
|> > machine with no floating point hardware so I would like to get rid of 
|> > floats entirely.
|> 
|> I sent him an integer square root code using Newton's Method.  I've done 
|> this problem before and I'm sure there are better methods out there.  Does 
|> somebody want to post/email something better than Newton's?
|> 
I have programmed several methods on a i386. Newton is the fastest if the mul instruction
is so slow as on a Intel. If multiplication is fast and division is slow, bit trying
and a newton cycle is an optimum. So I need the time of the div and mul and if the instruction
exist, of a bit search instruction to evalutate this problem. Is an error of a LSB critical (sqrt(24)=5) is another
question.

Frank