Searching \ for ' Fixed Point Arithmetic' 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/index.htm?key=fixed+point+arithmetic
Search entire site for: 'Fixed Point Arithmetic'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] Fixed Point Arithmetic'
2001\02\13@072610 by Rodrigo Araujo Real

flavicon
face
      Hi

      I'm having some trouble to work with some routines from AN617 (FXD0808U, FXM0808U). I don't know what is the format of the numbers. Could anyone help me?

      The routines from AN617 are the best choice? I also have some problems to compile them with tpasm under linux (I'm working with 16F877).

      Thanks in advance.

      Rodrigo Real

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


2001\02\13@080016 by Scott Dattalo

face
flavicon
face
On Tue, 13 Feb 2001, Rodrigo Araujo Real wrote:

>        Hi
>
>        I'm having some trouble to work with some routines from AN617 (FXD0808U, FXM0808U). I don't know what is the format of the numbers. Could anyone help me?
>
>        The routines from AN617 are the best choice? I also have some problems to compile them with tpasm under linux (I'm working with 16F877).

You oughta grab gpasm. Several enhancements in the last few weeks make it almost
100% compatible with MPASM.

http://www.dattalo.com/gnupic/gpasm.html

As for the fixed point stuff, geez I wish I had time to help.

Scott

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


2001\02\13@134154 by Rodrigo Araujo Real

flavicon
face
I wrote without the appropriate tag:
>        Hi
>
>        I'm having some trouble to work with some routines from AN617 (FXD0808
U, FXM0808U). I don't know what is the format of the numbers. Could anyone help
me?
>
>        The routines from AN617 are the best choice? I also have some problems
to compile them with tpasm under linux (I'm working with 16F877).
>
>        Thanks in advance.
>
>        Rodrigo Real
>

Scott Dattalo wrote:
>You oughta grab gpasm. Several enhancements in the last few weeks make it almos
t
>100% compatible with MPASM.

     In fact I was using tpasm, but I downloaded gpasm 0.8.15 and got these messages:
...
Error FXM88.A16 265 : 103 parse error
Error FXM88.A16 283 : 103 parse error
Error FXM88.A16 341 : 157 maybe_evaluateCan't evaluate expression
Error FXM88.A16 341 : 157 maybe_evaluateCan't evaluate expression
...

These errors repeated a lot, pointing to all lines that have labels like the one below.

     GOTO    UM0707NA#v(i)

Is it because of the hash simbol?


>As for the fixed point stuff, geez I wish I had time to help.

Could someone else give me a clue on that?
I tried to work with Q6.2 but it didn't work fine. Now I'm using the 1616 routin
es and working with Q10.6 (that's what I really want), but the results are far f
rom the expected.

[]s
Rodrigo Real

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


2001\02\13@134943 by Rodrigo Araujo Real

flavicon
face
I can't believe I did it again. Please forgive me. I promise I'm gonna be more carefull.

I wrote without the appropriate tag:
 >        Hi
 >
 >        I'm having some trouble to work with some routines from AN617 (FXD0808U, FXM0808U). I don't know what is the format of the numbers. Could anyone help me?
 >
 >        The routines from AN617 are the best choice? I also have some problems to compile them with tpasm under linux (I'm working with 16F877).
       Thanks in advance.
 >
 >        Rodrigo Real
 >

  Scott Dattalo wrote:
 >You oughta grab gpasm. Several enhancements in the last few weeks make it almost 100% compatible with MPASM.
 >In fact I was using tpasm, but I downloaded gpasm 0.8.15 and got these messages:
 ...
 Error FXM88.A16 265 : 103 parse error
 Error FXM88.A16 283 : 103 parse error
 Error FXM88.A16 341 : 157 maybe_evaluateCan't evaluate expression
 Error FXM88.A16 341 : 157 maybe_evaluateCan't evaluate expression
 ...

 These errors repeated a lot, pointing to all lines that have labels like the one below.

       GOTO    UM0707NA#v(i)

 Is it because of the hash simbol?


 >As for the fixed point stuff, geez I wish I had time to help.

 Could someone else give me a clue on that?
 I tried to work with Q6.2 but it didn't work fine. Now I'm using the 1616 routines and working with Q10.6 (that's what I really want), but the results are far from the expected.

[]s
 Rodrigo Real

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


2001\02\13@140638 by Rodrigo Araujo Real

flavicon
face
Rodrigo Araujo Real writes:
I can't believe I did it again. Please forgive me. I promise I'm gonna be more carefull.

 I wrote without the appropriate tag:
  >        Hi
  >
  >        I'm having some trouble to work with some routines from AN617 (FXD0808U, FXM0808U). I don't know what is the format of the numbers. Could anyone help me?
  >
  >        The routines from AN617 are the best choice? I also have some problems to compile them with tpasm under linux (I'm working with 16F877).
        Thanks in advance.
  >
  >        Rodrigo Real
  >

  Scott Dattalo wrote:
  >You oughta grab gpasm. Several enhancements in the last few weeks make it almost 100% compatible with MPASM.
  >In fact I was using tpasm, but I downloaded gpasm 0.8.15 and got these messages:
  ...
  Error FXM88.A16 265 : 103 parse error
  Error FXM88.A16 283 : 103 parse error
  Error FXM88.A16 341 : 157 maybe_evaluateCan't evaluate expression
  Error FXM88.A16 341 : 157 maybe_evaluateCan't evaluate expression
  ...

  These errors repeated a lot, pointing to all lines that have labels like the one below.

        GOTO    UM0707NA#v(i)

  Is it because of the hash simbol?


  >As for the fixed point stuff, geez I wish I had time to help.

  Could someone else give me a clue on that?
  I tried to work with Q6.2 but it didn't work fine. Now I'm using the 1616 routines and working with Q10.6 (that's what I really want), but the results are far from the expected.

 []s
 Rodrigo Real

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


2001\02\13@222825 by Nikolai Golovchenko

flavicon
face
The routines in AN617 are simply integer routines, not fixed point.
If you have troubles with multi-byte variables, try to change the byte
order. Byte 0 is usually the most significant byte in Microchip's
routines.

There are a few fixed point routines at http://www.piclist.com but not much.
So, what are you looking for?

Nikolai

---- Original Message ----
From: Rodrigo Araujo Real <spam_OUTrodrigoTakeThisOuTspamFREEDOM.IND.BR>
Sent: Tuesday, February 13, 2001 14:17:32
 To: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
Subj: Fixed Point Arithmetic

{Quote hidden}

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


2001\02\13@235159 by Scott Dattalo

face
flavicon
face
On Tue, 13 Feb 2001, Rodrigo Araujo Real wrote:

>
>    Scott Dattalo wrote:
>    >You oughta grab gpasm. Several enhancements in the last few weeks make it almost 100% compatible with MPASM.
>    >In fact I was using tpasm, but I downloaded gpasm 0.8.15 and got these messages:
>    ...
>    Error FXM88.A16 265 : 103 parse error
>    Error FXM88.A16 283 : 103 parse error
>    Error FXM88.A16 341 : 157 maybe_evaluateCan't evaluate expression
>    Error FXM88.A16 341 : 157 maybe_evaluateCan't evaluate expression
>    ...
>
>    These errors repeated a lot, pointing to all lines that have labels like the one below.
>
>          GOTO    UM0707NA#v(i)
>
>    Is it because of the hash simbol?

It's a bug in gpasm. The good news is that Microchip has provided us with the
test files they use to test MPASM. Craig Franklin, a new member to the gpasm
team, has been tearing it up lately. He'll go through these files and figure out
where gpasm has defeciencies.

>
>
>    >As for the fixed point stuff, geez I wish I had time to help.
>
>    Could someone else give me a clue on that?
>    I tried to work with Q6.2 but it didn't work fine. Now I'm using the 1616
> routines and working with Q10.6 (that's what I really want), but the results
> are far from the expected.

Yeah, can some give Rodrigo some help!

Why don't you shed some light on what you're doing. You'll get 15 different
suggestions on how to do it better!

Scott

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


2001\02\16@051214 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,
Nikolai wrote: ( spelling correct now :) )

>The routines in AN617 are simply integer routines, not fixed point.
>If you have troubles with multi-byte variables, try to change the byte
>order. Byte 0 is usually the most significant byte in Microchip's
>routines.

uh ? ..is this not the beauty of fixed point ? ..you treat everything
like integers ( i.e. dp is only implied ) , ofcource you have to make
sure all data has the same scale factor but apart fromthat it is integer
math
only isn't it ? ( absolute easiest is to have dp at byte boundary
for example 8Q8 or 16Q8, make scaling of input dead easy ).


And yes to concure, what does the original poster want to accomplish ?

/Tony


Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: tony.kubekspamKILLspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\16@063723 by Rodrigo Araujo Real

flavicon
face
Tony writes:
> Hi,
> Nikolai wrote: ( spelling correct now :) )
>
> And yes to concure, what does the original poster want to accomplish ?
>

I just wanted to divide and multiply some numbers using fixed point routines. I got that with some routines downloaded from piclist web site (I'm still trying to fully understand them, but it's working already) . The problem is the that I am a newbie in low level programming, so I had to study a little bit to understand that stuff.

Thanks again to all that spent some time reading my messages (specially to the ones that reply them :) ).

[]s
Rodrigo Real

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\16@064338 by D Lloyd

flavicon
face
part 1 1407 bytes content-type:text/plain; charset=us-ascii
Hi,

There is a large (and good) section on fixed point math in the classic
Labrosse "Embedded System Building Blocks in C" (or whatever it is called
(!)) book..........


Dan






(Embedded     Rodrigo Araujo Real <.....rodrigoKILLspamspam.....FREEDOM.IND.BR>KILLspamspam.....MITVMA.MIT.EDU>> image moved   16/02/2001 11:39
to file:
pic03276.pcx)





Please respond to pic microcontroller discussion list
     <
EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Sent by:  pic microcontroller discussion list <PICLISTspamspam_OUTMITVMA.MIT.EDU>


To:   @spam@PICLISTKILLspamspamMITVMA.MIT.EDU
cc:
Subject:  Re: [PIC]: Fixed Point Arithmetic

Security Level:?         Internal


Tony writes:
> Hi,
> Nikolai wrote: ( spelling correct now :) )
>
> And yes to concure, what does the original poster want to accomplish ?
>

I just wanted to divide and multiply some numbers using fixed point
routines. I got that with some routines downloaded from piclist web site
(I'm still trying to fully understand them, but it's working already) . The
problem is the that I am a newbie in low level programming, so I had to
study a little bit to understand that stuff.

Thanks again to all that spent some time reading my messages (specially to
the ones that reply them :) ).

[]s
Rodrigo Real

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads






part 2 165 bytes content-type:application/octet-stream; (decode)

part 3 154 bytes
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\16@231603 by Nikolai Golovchenko

flavicon
face
Hi Tony,

Well, it really depends on what you are doing. Sometimes integer
routines can be used with fixed point data, but not as often as you
would like.

Nikolai

P.S. Thanks for correcting my name :) In fact, there are so many
variants of spelling that I don't know really what is more correct...

---- Original Message ----
From: Kübek Tony <KILLspamtony.kubekKILLspamspamFLINTAB.COM>
Sent: Friday, February 16, 2001 11:54:43
 To: RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
Subj: [PIC]: Fixed Point Arithmetic

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\17@120538 by Olin Lathrop

face picon face
> Well, it really depends on what you are doing. Sometimes integer
> routines can be used with fixed point data, but not as often as you
> would like.

Oh, and why not?  Fixed point numbers ARE integers.  The difference is a
fixed point number has some implied power of 2 multiplier that only you know
about.  The next step up is floating point which explicitly stores the
multiplier so that it can be adjusted at run time.  Yes, you have to
normalize fixed point number before you add or subtract them, but the actual
add, subtract, multiply, divide operations are just integer.


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

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\17@131249 by Sean H. Breheny

face picon face
Hi Olin,

Add,subtract,and divide should be the same, but multiply requires that you
take the multiplier into account, AFAIK. So does square root, or
sine/cosine, or any other unary function, or any situation where the
multiplier wouldn't cancel out.

For example, in base 10, if I have 00100 and 00400 (and they really mean
10.0 and 40.0 because my standard multiplier is 10), then when I multiply
them, I get 40000, which would be 4000.0 instead of 400.0. So, I have to
follow up every multiply with a division by the standard multiplier (which
is only a shift in this case, but still not exactly the same as just an
integer multiply operation).

I'm not sure what you mean by "normalizing" before addition and
subtraction. It seems to me that it works just fine without any changes
(e.g. 00400 - 00100 = 00300, which is 40.0 - 10.0 = 30.0, which is
correct), but perhaps there are cases I'm not seeing.

Sean


At 09:37 AM 2/17/01 -0500, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\17@163713 by Spehro Pefhany

picon face
At 09:37 AM 2/17/01 -0500, you wrote:
>
>Oh, and why not?  Fixed point numbers ARE integers.  The difference is a
>fixed point number has some implied power of 2 multiplier that only you know
>about.  The next step up is floating point which explicitly stores the
>multiplier so that it can be adjusted at run time.  Yes, you have to
>normalize fixed point number before you add or subtract them, but the actual
>add, subtract, multiply, divide operations are just integer.

I don't know about yours, but *my* fixed-point routines are different thusly

1)      They throw away part of the results of a multiply (and add it before
       a divide) that is different from the default behavior of a C compiler,
       say.

2)      They do sensible things when you overflow (saturate with the same
       sign, say), so there are less things to worry about in things such
       as control loops. Most integer routines just overflow and change
       sign willy-nilly, so you have to check the numbers before (almost)
       every operation. Even "change-sign" can create an error if you are
       using 2's complement numbers.

3)      There's no normalization except when you convert to or from the
       outside world or when you are rationalizing two representations to
       add or subtract, then you have to >> or << however many bits (and
       maintain the sign, and not overflow, and deal with it sensibly
       if you do allow overflow and it does overflow).

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffEraseMEspam.....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 list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\17@182423 by Bill Westfield

face picon face
   > Well, it really depends on what you are doing. Sometimes integer
   > routines can be used with fixed point data, but not as often as you
   > would like.

   Oh, and why not?  Fixed point numbers ARE integers.

You have to do things different on multiply and divide so that the "point"
stays in a fixed place.  Say you have 8 bits of fraction and 8 bits of
integer, so 1.5 is 0x0180.  An integer multiple of 0x180*0x180 would give
you 24000 - an overflow in integer arithmetic but NOT for fixed point.  In
this case you want the MIDDLE bits: 0x0240 is 2.25  (the bottom bits are
fractions of fractions, and not so significant.)

(I assume that's what Olin meant by "normalize", but I wanted to spell it
all out.)

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\17@193855 by Olin Lathrop

face picon face
> I'm not sure what you mean by "normalizing" before addition and
> subtraction.

Normalizing in this context means making sure both numbers have the binary
point in the same place.  You can't just add a 14.2 and a 13.3 fixed point
numbers as two 16 bit integers.  But you can just add two 13.3 fixed point
numbers, for example.


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

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\18@065930 by Nikolai Golovchenko

flavicon
face
Because the fixed point numbers AREN'T integers. Normalization is a
trick to make the integer routines work with fixed point numbers. It's
like crutches to make an invalid walk. The person wouldn't walk very
well. Why not use floating point too? With a bit of normalization
would work too... I hate to generalize, but it all depends on a
particular situation.

Nikolai

---- Original Message ----
From: Olin Lathrop <RemoveMEolin_piclistEraseMEspamEraseMEEMBEDINC.COM>
Sent: Saturday, February 17, 2001 16:37:04
 To: RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU
Subj: [PIC]: Fixed Point Arithmetic

{Quote hidden}

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


2001\02\18@120505 by Olin Lathrop

face picon face
> You have to do things different on multiply and divide so that the "point"
> stays in a fixed place.  Say you have 8 bits of fraction and 8 bits of
> integer, so 1.5 is 0x0180.  An integer multiple of 0x180*0x180 would give
> you 24000 - an overflow in integer arithmetic but NOT for fixed point.  In
> this case you want the MIDDLE bits: 0x0240 is 2.25  (the bottom bits are
> fractions of fractions, and not so significant.)

You are assuming that you want the product with the same number of fraction
bits as the two original numbers, or that those numbers even have the same
number of fraction bits in the first place.  I find that when I'm using
fixed point heavily, different values often have different numbers of
fraction bits.  The beauty is that you still do the same integer math for
the actual crunching, although you have to be aware of how many fraction
bits each value has.

Hmm, 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.  Maybe that's because I use mostly assembler on small
resource-limited systems.

> (I assume that's what Olin meant by "normalize", but I wanted to spell it
> all out.)

There is an additional wrinkle when adding two fixed point numbers.  You
have to make sure they both have the same number of fraction bits before
doing the integer add.  This step is usually called "normalization".  It
occurs implicitly inside floating point add routines.


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

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


'[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
RemoveMEwalterKILLspamspambytecraft.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"
speffSTOPspamspamspam_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@140756 by Bob Ammerman

picon face
>
> You are assuming that you want the product with the same number of
fraction
> bits as the two original numbers, or that those numbers even have the same
> number of fraction bits in the first place.  I find that when I'm using
> fixed point heavily, different values often have different numbers of
> fraction bits.  The beauty is that you still do the same integer math for
> the actual crunching, although you have to be aware of how many fraction
> bits each value has.
>
> Hmm, 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.  Maybe that's because I use mostly assembler on small
> resource-limited systems.

It is possible to design a set of fixed point classes with C++ which
automagically handle scaling issues. It is non-trivial to avoid unnecessary
runtime overhead in such classes. [Hint: heavy use of templates required].

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@141215 by Bob Ammerman

picon face
----- Original Message -----
From: Spehro Pefhany <spamBeGonespeffSTOPspamspamEraseMEINTERLOG.COM>
To: <KILLspamPICLISTspamBeGonespamMITVMA.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"
EraseMEspeffspamEraseMEinterlog.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"
@spam@speff@spam@spamspam_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
spamBeGonewalterspamKILLspambytecraft.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"
.....speffspam_OUTspaminterlog.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, TakeThisOuTolin.....spamTakeThisOuTembedinc.com, http://www.embedinc.com

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


2001\02\19@055345 by Bill Westfield

face picon face
   You are assuming that you want the product with the same number of
   fraction bits as the two original numbers, or that those numbers even
   have the same number of fraction bits in the first place.

Yes, I'm assuming that "fixed point" implies the same number of fractional
bits throughout a system, or at least a subsystem.


   I find that when I'm using fixed point heavily, different values often
   have different numbers of fraction bits.

I hadn't thought that would be common, but I'll bow to someone with more
actual experience using fixed point.  I'd consider this more of a
simplified floating point scheme, with the "exponent" stored "externally"
(ie in the programer's head.)


   Hmm, 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.

IIRC, PL/1 had fixed point support of some kind.  Never used it myself,
except for the trivial "integer" usage.  I don't know whether it would do
things like convert to allow math between variables with different decimal
place positions, or whether it would just flag attempts at such as an error.

BillW

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


2001\02\19@061010 by Vasile Surducan

flavicon
face
Sorry for my interference in this subject but can you point to a good
site or documentation in which "fixed point arithmetic" to be well
described ?
Vasile


On Mon, 19 Feb 2001, William Chops Westfield wrote:

{Quote hidden}

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


2001\02\19@061425 by Bond Peter S-petbond1

flavicon
face
> Sorry for my interference in this subject but can you point to a good
> site or documentation in which "fixed point arithmetic" to be well
> described ?
> Vasile

This might serve as a start point:

http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=fixed-point

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.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 listservEraseMEspammitvma.mit.edu with SET PICList DIGEST in the body


2001\02\19@111941 by Don Hyde

flavicon
face
Do you have or know of a source of example code for good fixed-point
routines for PIC's?

Do you know of a good textbook that discusses fixed-point arithmetic?  I've
been working on a project in which I have had to perform some computations
with a PIC at speeds I didn't think a PIC could deliver, but I seem to be
getting there.  The hardest part is that everything I know about scaling and
other issues of fixed-point computations has been lying unused in the back
of my head for the better part of 30 years, and I've had very little luck
trying to find a book I can look it up in to refresh those ancient memories.

Every book I can find talks a little about integers, shows you half-adders
and full-adders, mentions that that you COULD do fixed-point arithmetic, and
then goes on about how REAL computers have floating-point units, and into a
discussion on how to build a floating-point unit.

SNIP

> I don't know about yours, but *my* fixed-point routines are
> different thusly
>
SNIP

> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-=-=-=-=
> Spehro Pefhany --"it's the network..."            "The
> Journey is the reward"
> RemoveMEspeffEraseMEspamspam_OUTinterlog.com             Info for manufacturers:

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


2001\02\19@124156 by Spehro Pefhany

picon face
At 10:20 AM 2/19/01 -0600, you wrote:

>Do you know of a good textbook that discusses fixed-point arithmetic?  I've
>been working on a project in which I have had to perform some computations
>with a PIC at speeds I didn't think a PIC could deliver, but I seem to be
>getting there.  The hardest part is that everything I know about scaling and
>other issues of fixed-point computations has been lying unused in the back
>of my head for the better part of 30 years, and I've had very little luck
>trying to find a book I can look it up in to refresh those ancient memories.

Nope, I don't. I've worked it out myself as required, to do polys, PID,
whatever.  The calculations are not so much different from any other method
just that you have to watch for overflow and loss of resolution. These
can crop up easily with floating-point numbers too, so it's mostly a special
case of numerical analysis topics.

If there is something that specifically covers these issues (maybe with some
software tools), I'd be interested to know about it.

Best regards,



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
EraseMEspeffspam@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#nomail Going offline? Don't AutoReply us!
email @spam@listservspam_OUTspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\02\19@235300 by Nikolai Golovchenko

flavicon
face
There is a fixed-point blockset for MATLAB that addresses these
problems. It has a big pdf document (2.5 MB) describing among other
things various fixed point formats (as used in the blockset). Might be
useful.

http://www.mathworks.com/access/helpdesk/help/pdf_doc/fixpoint/fp_blks.pdf


Nikolai

---- Original Message ----
From: Spehro Pefhany <spamBeGonespeffEraseMEspamINTERLOG.COM>
Sent: Monday, February 19, 2001 19:43:59
 To: PICLISTspamBeGonespamMITVMA.MIT.EDU
Subj: [PIC]: Fixed Point Arithmetic

{Quote hidden}

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


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