cottrell@nbs-vms.ARPA (COTTRELL, JAMES) (10/02/85)
> > > 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. jim cottrell@nbs */ ------
henry@utzoo.UUCP (Henry Spencer) (10/04/85)
> > Great, a violation of the C language spec in the kernel. [16-bit float] > > 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. Nope, wrong. The format is 3 bits of exponent and 13 bits of mantissa, which does not correspond to *any* hardware format. It is hand-cooked using bit-manipulation operations, fairly portably. No violation of standards is involved; it's simply a compressed data format unique to this particular application. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
rjh@ihlpa.UUCP (Herber) (10/04/85)
> > > > 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. > > jim cottrell@nbs > */ > ------ The "float:16" construct is contructed in a machine-independent fashion in the accounting routines by shifting bits and or-ing. The values are always positive; therefore there is no mantissa sign bit. And, since the values are integers, the exponent field is not offset. The values are using to accumulate values like CPU-clockticks used by a process against a uid. The "floating-point" (I would call it "scaled integer") format is used to support a large dynamic range. Randolph J. Herber
john@frog.UUCP (John Woods) (10/08/85)
> > > > 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
cottrell@NBS-VMS.ARPA (COTTRELL, JAMES) (10/08/85)
/* > d) Using the comp_t code lets you keep the size of (struct acct) > to 32 bytes. It is moderately helpful that this size be a power of > 2 so that the struct never cross disk buffer boundaries. Having struxures be a power of two bytes in size is good for indexing and display as well. I recommend it heartily. jim cottrell@nbs */ ------