Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site frog.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!think!mit-eddie!cybvax0!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: net.lang.c
Subject: Re: Float:16
Message-ID: <258@frog.UUCP>
Date: Mon, 7-Oct-85 18:24:55 EDT
Article-I.D.: frog.258
Posted: Mon Oct  7 18:24:55 1985
Date-Received: Sun, 13-Oct-85 03:04:45 EDT
References: <1869@brl-tgr.ARPA>
Organization: Charles River Data Systems, Framingham MA
Lines: 25

> > > > Then you can define
> > > > float foo:16;
> > > > if you really think you can do something useful with 16-bit floats. Someone
> > > > must use them for something...
> > > Just such a construct is used in the accounting software in many UNIX System
> > > kernels.  It seems to suffice for the application.
> > Great, a violation of the C language spec in the kernel.
> Not really. I haven't axually seen it, but here's my theory:
> There must be a union of short[2] & float somewhere in the (which?) 
> kernel. The magic numbers are computed in float and the short[0] is
> written out to a file, the lower mantissa bits being deemed worthless.
> Not a violation, just (nonportable) bit fiddling.
> 
The last time I looked at process accounting, what goes on is that they define
16-bit floating point arithmetic in software; e.g., they take a short, and
do appropriate masks and shifts to make it work.  Read Knuth or some other
source to learn how to simulate floating point hardware (or to learn what it
is that floating point hardware simulates).

--
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA

"Out of my way, I'm a scientist!"
			- War of the Worlds