Searching \ for '[PIC]: Fixed Point Arithmetic and ISO' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Fixed Point Arithmetic and ISO'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Fixed Point Arithmetic and ISO'
2001\02\18@130643 by Walter Banks

picon face
> ... this might be a service a compiler could provide.  Standard C has no
> such thing as a fixed point data type, but this could be useful for small
> resource-limited systems.  Suppose you could declare the total number of
> bits and the number of fraction bits, then just write the code with the
> normal math operators.  The compiler would emit code to adjust results to
> the fixed number of fraction bits you specified for the variable the result
> is being stored into.  I'm sure some compiler does this already, but I don't
> know of any.

ISO is working on a series C support of proposals for embedded systems.
Two of these proposals are directly related to C support for fixed point
math. The essential difference between them is one has supports fixed
point math as fractional math and the other very similar to the Olin's
description where variables are declared with fixed and fractional parts
and compilers are responsible for assuring normalizing the results.

ISO released C99 in December 1999 (Adopted by ANSI in April 2000) which
contained several changes largely in response to non hosted
requirements.
The availability of additional data types and boolean data types has
been
well received.

The very fact that ISO/ANSI are working on standards for embedded
systems can only be looked at as a good thing. Now might be a
good time to air wish lists for embedded programming standards.

Walter Banks
spam_OUTwalterTakeThisOuTspambytecraft.com
1 519 888 6911

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@135116 by Spehro Pefhany

picon face
At 01:03 PM 2/18/01 -0500, you wrote:

>The very fact that ISO/ANSI are working on standards for embedded
>systems can only be looked at as a good thing. Now might be a
>good time to air wish lists for embedded programming standards.

Finally!

How would one go about this?

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@141215 by Bob Ammerman

picon face
----- Original Message -----
From: Spehro Pefhany <speffspamKILLspamINTERLOG.COM>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Sunday, February 18, 2001 1:53 PM
Subject: Re: [PIC]: Fixed Point Arithmetic and ISO


> At 01:03 PM 2/18/01 -0500, you wrote:
>
> >The very fact that ISO/ANSI are working on standards for embedded
> >systems can only be looked at as a good thing. Now might be a
> >good time to air wish lists for embedded programming standards.
>
> Finally!
>
> How would one go about this?

I could be wrong, but I think it is probably (close to?) too late to get
anything into the next version of the C standard.

Also, while the next "C" is supposed to do a better job with mapping integer
types to application requirements, it does _not_, AFAIK, do much if anything
in the way of fixed point.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@144124 by Spehro Pefhany

picon face
At 02:10 PM 2/18/01 -0500, you wrote:

>I could be wrong, but I think it is probably (close to?) too late to get
>anything into the next version of the C standard.

I'm using ANSI/ISO/IEC/ 9899:1999 (E), so I'd imagine there's time before the
next one. (Date of ANSI Approval: 5/22/2000). It's been about 10 years
since the
last one (ANS X3.159-1989) was released.

Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
EraseMEspeffspam_OUTspamTakeThisOuTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@150820 by Bob Ammerman

picon face
> >I could be wrong, but I think it is probably (close to?) too late to get
> >anything into the next version of the C standard.
>
> I'm using ANSI/ISO/IEC/ 9899:1999 (E), so I'd imagine there's time before
the
> next one. (Date of ANSI Approval: 5/22/2000). It's been about 10 years
> since the
> last one (ANS X3.159-1989) was released.
>
> Best regards,
> Spehro Pefhany


Right, I guess I wasn't aware the approval was final.

So, yeah you'd have  while to get in ideas before the next version.

But it'll be a long while before the next version comes out.

Anyway Spehro, is there any support for fixed point in the 1999 version?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@154558 by Spehro Pefhany

picon face
At 03:08 PM 2/18/01 -0500, you wrote:

>So, yeah you'd have  while to get in ideas before the next version.
>But it'll be a long while before the next version comes out.

And even longer for conforming compilers to be available. Still,
as Lao Tzu said "A journey of a thousand li starts with a single step". ;-)

>Anyway Spehro, is there any support for fixed point in the 1999 version?

I don't see much in the dense 550+ page document. There is some new
stuff (I think) on integer *formatting* but that doesn't look all that
significant (see <inttypes.h> and <stdint.h>) .

You can define exact width, greatest width, minimum width, and
fastest minimum width integers as well as integers large enough to
hold pointers to objects. For example, int_t8 would be a signed
integer of width exactly 8 bits).

In total, I see nothing of much consequence in this department for us.

You'd think they'd be more on the ball about it with all the DSPs
out there, many of them using fixed point. Big dollars.

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamspam_OUTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@160708 by Walter Banks

picon face
Spehro Pefhany wrote:

> >The very fact that ISO/ANSI are working on standards for embedded
> >systems can only be looked at as a good thing. Now might be a
> >good time to air wish lists for embedded programming standards.
>
> Finally!
>
> How would one go about this?

Informally we can do it here. There is enough circulation
in this group to get noticed.

The important thing is to get idea's out where they
can be debated by the developers and tool providers
who are the people most impacted by standards changes.

Walter Banks
@spam@walterKILLspamspambytecraft.com
1 519 888 6911

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@170436 by Bob Ammerman

picon face
> You can define exact width, greatest width, minimum width, and
> fastest minimum width integers as well as integers large enough to
> hold pointers to objects. For example, int_t8 would be a signed
> integer of width exactly 8 bits).
>
> In total, I see nothing of much consequence in this department for us.
>
> You'd think they'd be more on the ball about it with all the DSPs
> out there, many of them using fixed point. Big dollars.
> Best regards,
>
> Spehro Pefhany

Yeah, most of this stuff is designed to help write portable programs with
decent performance. Not a lot of help for writing the best/fastest code for
a specific microcontroller platform.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@191454 by Walter Banks

picon face
Bob Ammerman wrote:
> Yeah, most of this stuff is designed to help write portable programs with
> decent performance. Not a lot of help for writing the best/fastest code for
> a specific microcontroller platform.


Code generators for good compilers are written for specific
targets. A well implemented compiler will do a better job
when the application developer can concisely express themselves.
I am all in favor of the extending data types and the addition
of saturated variables.

One of the studies that we did was to look at applications
that used 32 bit variables. We found that most could be
implemented with 24 bit variables. In embedded systems using
8 bit data paths 24 vs 32 makes a difference.


Walter Banks

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\18@200314 by Spehro Pefhany

picon face
At 07:11 PM 2/18/01 -0500, you wrote:

>Code generators for good compilers are written for specific
>targets. A well implemented compiler will do a better job
>when the application developer can concisely express themselves.
>I am all in favor of the extending data types and the addition
>of saturated variables.

Yes. I say extend the data types, add saturated variables.
I don't see a need for unsigned (just as there is
no need for unsigned floats).

Figure out some way to tell the compiler how to adjust
numbers before and after multipications and divisions (as
required). The rest can be handled by the library.

>One of the studies that we did was to look at applications
>that used 32 bit variables. We found that most could be
>implemented with 24 bit variables. In embedded systems using
>8 bit data paths 24 vs 32 makes a difference.

I've found 32 bit variables necessary for evaluation of
higher degree polynomials and time. I tend to mix 16
and 32 bit (16 bits is enough for *most* A/D inputs and
such like, and almost always enough for outputs),
having little use for 24, but if it was available, i'd
probably use it from time to time.

Right now I implement a RPN stack and manage it myself
for 16/32 bit calculations, but I see no reason why a
sufficiently clever compiler might not be able to do
so almost as well, and with somewhat less effort.

I've used this method on PIC, 68HCx05/8, 68HC12, 80C51,
65C02, etc. so there seems to be little machine dependence,
some processors are more efficient than others, but
those things tend to even out in the end.

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
KILLspamspeffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\19@001002 by Olin Lathrop

face picon face
> I don't see a need for unsigned (just as there is
> no need for unsigned floats).

Unsigned integers and fixed point numbers can be very useful.  There are
lots of cases when you know a number can't be negative, or where negative
just doesn't make any sense.  Unsigned integers also wrap or overflow
differently than signed in ways that can be very useful.  Probably the
majority of integers I use are unsigned.

> Figure out some way to tell the compiler how to adjust
> numbers before and after multipications and divisions (as
> required). The rest can be handled by the library.

I don't see why multiplication or division should be special.  Normalization
before addition certainly sounds useful.

> I've found 32 bit variables necessary for evaluation of
> higher degree polynomials and time. I tend to mix 16
> and 32 bit (16 bits is enough for *most* A/D inputs and
> such like, and almost always enough for outputs),
> having little use for 24, but if it was available, i'd
> probably use it from time to time.

I usually use 24 bit floating point with 16 mantissa bits for things like
polynomials, PID control loops and the like.  One part in 65000 is usually
plenty for any real world measured or produced values.  However, I find more
bits are often needed for fixed point values because of dynamic range
issues.  I've ended up with 32 bit integer routines and 24 bit floating
point routines.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\02\19@070315 by mike

flavicon
face
>The very fact that ISO/ANSI are working on standards for embedded
>systems can only be looked at as a good thing. Now might be a
>good time to air wish lists for embedded programming standards.
Probably highest on my wishlist would be :
A 24-bit 'medium' data type
Support for the carry bit for rotate ops
Strings that allow zero bytes to be included
Nested procedures to improve efficiency of local variable usage.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...