Message-Id: <199804110246.WAA07393@renoir.op.net>
Comments: Authenticated sender is <edgee@cyberpass.net>
From: "Ed G." <edgee@cyberpass.net>
To: pups@minnie.cs.adfa.oz.au
Date: Fri, 10 Apr 1998 22:40:34 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Floating Point-How Important to Unix?
Reply-to: edgee@cyberpass.net
CC: Johnny Billquist <bqt@Update.UU.SE>
References: <199804080325.XAA26777@renoir.op.net>
In-reply-to: <Pine.VUL.3.93.980408094723.13372A-100000@Zeke.Update.UU.SE>
Sender: owner-pups@minnie.cs.adfa.oz.au
Precedence: bulk

I'd like to thank everyone who wrote me on this subject, 
and especially those described the weaknesses they saw in my 
reasoning.  

I have found it useful sometimes to take a step back and reconsider 
what it is I am trying do and how I am trying to do it.  

My purpose here was to get a sense for how heavily the Unix utilities
rely on floating point.  I was not looking for a numerically exact 
"right" answer, but rather an estimate which was good enough.

At this point, now that I have access to the source code, it seems to 
me that an easier and more accurate way of doing that would be to 
count the occurences of floats and doubles using grep or a similar 
utility.  What do you all think?

> You are making atleast four assumptions which are wrong here.
> 
> 1) Data starts from address 0. They most likely do not.

I'm not sure what you mean here; can you elaborate?  

As I see it my key assumption about data was that it is 
relatively small in size compared to code in a given program file.  
This was certainly the case with factor, where less than 10% of the 
runtime image consisted of static data.

> 2) 17 is not 6 bits, it's four! You are talking about octal representation
>    of 16 bits, which means that the highest digit can only be 0 or 1.

You are absolutely right.  Thank you for pointing this out.  

> 3) All data are not words. How about bytes? If a byte is in the range
>    240-255 and on an odd address, you'll catch it as a FP opcode.

My routine scanned words, not bytes, so I don't think this would 
apply.

> 4) Not all data are addresses. Most negative numbers will have 17 as the
>    high four bits.

This is true.  But if data is negligible compared to code, then I
don't see how this wouldn't affect an estimate very much.

Ed