Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!natinst!rpp386!woody
From: woody@rpp386.cactus.org (Woodrow Baker)
Newsgroups: comp.lang.c
Subject: Re: Shouldn't ANSI have provided nonvolatile instead of volatile?
Summary: uses
Message-ID: <17950@rpp386.cactus.org>
Date: 15 Feb 90 18:58:52 GMT
References: <1117.18:37:35@stealth.acf.nyu.edu> <1990Feb8.162440.22318@utzoo.uucp> <1990Feb13.114041.4178@bath.ac.uk>
Organization: River Parishes Programming, Plano, TX
Lines: 56

In article <1990Feb13.114041.4178@bath.ac.uk>, exspes@bath.ac.uk (P E Smee) writes:
> In article <1990Feb12.182343.14269@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
> >In article <17910@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
> >>FIXED  i.e. fixed point math.  This type would deal with chars,ints, longs
> >>and quads.  There would be an assumed binary point in the middle of the
> >>data...
> >
> >But *I* want the assumed binary point three bits from the right! :-)  This
> >whole area is a massive swamp of conversion rules, overflow handling, etc.
> 
> PL/1 offered that.  In years of PL/1 programming, I believe I only ever
> saw two or three programs (by anyone) that used it.  A declaration such
> as 'fixed bin (31, 6)' meant you wanted a fixed-point number 31 bits
> long, with the assumed binary point 6 bits from the right (or was it
> the left?).  It had the advantage over C that you didn't have the
> long/int/short/char porting problems -- you said how many BITS you
> needed for the value, and let the compiler worry about how many of what
> sort of storage units that implied.  (The compiler could pad for
> alignment -- unless you forbade it.)
> 
> It had the disadvantage that the conversions (particularly when
> operating on operands of different types) were so baroque that it was
> actually usually easier to simply declare everything as 'fixed bin
> (n,0)' (effectively, int/long/short) and to keep track of any assumed


hmmm.  Where it would be useful, would be in scaling operations.  Scaling
things like thermocouple readings, and so forth, using 'C', you have the
overhead of a floating point package.  IF you are developing code to say,
fit in a 4k 8051, you can't afford the codespace for a FP, but fixed
integer would substitue nicely.

People, missed my point, that fixed point does not require conversions.
A fixed int and an int are the same thing.  i.e., they should substitue
for each other.  It is merely where you have the binary point.  Conversion
to and from float, fixed, and int are not a problem.  fixed to float is
real easy, float to fixed is also easy.  It is up to the programmer to be sure
that the floating number is within range of the fixed point number that you
are converting it to.  conversion to and from integer, merely is moving
the bit pattern,  It would be up to the programmer to truncate the
fraction portion first, if he so desired.  Anything that needs fast, non-
integer math would benefit.  Postscript interpreters, batch control and
weighting systems, etc.

Tom Plum, told me that the QUAD idea was mentioned, but died "because it
had no champion".  Fixed wasn't even thought of.  It seems that the
average joe programmer can't influence things like standards committees
easily.  How do you manage to get onto a commitee like that?  How
do you get to attend the meetings and present ideas?  I never found any addresses, schedules, contact points, meeting places or dates published in
normal industry traderags, or special magazines, like DR. Dobbs,
or PC week
etc.... Perhaps PC week would not be a good place, but it is rather
widely followed....
Cheers
Woody