nanook@eskimo.celestial.com (Robert Dinse) (04/28/91)
I am trying to write a program that looks at system accounting data
and figures out what programs use how much CPU time.
The file has a structure that has several items in a data type
"comp_t", which is packed into an unsigned short (16 bits). The
comments say:
/* 13-bit fraction, 3-bit exponent */
This is on a Tandy 6000 running Xenix 3.02.01.
Can anybody tell me how to turn this funny 16-bit float into an
interger number? This is used for CPU time in clock ticks.chap@art-sy.detroit.mi.us (j chapman flack) (05/06/91)
In article <512@eskimo.celestial.com> nanook@eskimo.celestial.com (Robert Dinse) writes: >"comp_t", which is packed into an unsigned short (16 bits). The >comments say: > > /* 13-bit fraction, 3-bit exponent */ I just messed with that recently myself. By running a bunch of commands that took known amounts of time (sleep(1) is handy for that) and trying to make sense of the resulting comp_ts, I came up with the following theory: mantissa = comp_t & 0x1FFF exponent = comp_t & 0xE000 double ticks = ldexp( (double)mantissa, 3*exponent) The extra factor of 3 in the exponent bothers me, but it was consistent with the various values I tried. You'll probably want to run a number of trials yourself. I would be delighted, actually, to learn that I'm wrong and have someone provide a more sensible explanation. Wouldn't it be nice if AT&T's comment included the information that needs to be included? -- Chap Flack Their tanks will rust. Our songs will last. chap@art-sy.detroit.mi.us -Mikos Theodorakis Nothing I say represents Appropriate Roles for Technology unless I say it does.
pefv700@perv.pe.utexas.edu (05/08/91)
In article <9105060921.aa11316@art-sy.detroit.mi.us>, chap@art-sy.detroit.mi.us (j chapman flack) writes... >mantissa = comp_t & 0x1FFF >exponent = comp_t & 0xE000 > >double ticks = ldexp( (double)mantissa, 3*exponent) > I would be delighted, actually, to learn that I'm wrong and have >someone provide a more sensible explanation. Try ticks = (double)((comp_t & 0x1fff) << 3 * (comp_t & 0xe000)); The reason your ldexp call is correct is that it is mantissa times (8 to the power exponent) or more literally mantissa times (2 to the power (3 times exponent)) This can be done quicker with a left shift. As K&R2 says, The value of E1<<E2 is E1 (interpreted as a bit pattern) left-shifted E2 bits; in the absence of overflow, this E2 is equivalent to multiplication by 2 . Chris
nanook@eskimo.celestial.com (Robert Dinse) (05/11/91)
In article <9105060921.aa11316@art-sy.detroit.mi.us>, chap@art-sy.detroit.mi.us (j chapman flack) writes: # In article <512@eskimo.celestial.com> nanook@eskimo.celestial.com (Robert Dinse) writes: # >"comp_t", which is packed into an unsigned short (16 bits). The # >comments say: # > # > /* 13-bit fraction, 3-bit exponent */ # # I just messed with that recently myself. By running a bunch of commands that # took known amounts of time (sleep(1) is handy for that) and trying to make # sense of the resulting comp_ts, I came up with the following theory: # # mantissa = comp_t & 0x1FFF # exponent = comp_t & 0xE000 # # double ticks = ldexp( (double)mantissa, 3*exponent) # # The extra factor of 3 in the exponent bothers me, but it was consistent with # the various values I tried. You'll probably want to run a number of trials # yourself. I would be delighted, actually, to learn that I'm wrong and have # someone provide a more sensible explanation. Actually this makes perfect sense. I found an include file on a different system that had notes that were just a tad more explicit. Specifically they stated that the exponent was base 8. Now, ldexp takes an exponent in base 2, 2 to the third power is 8, and so that adjustment of exponent * 3 does exactly what you need, effectively converting ldexp from base 2 to base 8. I am curious how you arrived at that formula, but now all things considered it makes sense. Thanks for following up on my post!