No exact or substring matches. trying for part
PICList
Thread
'[PICLIST] Fixed Point Arithmetic'
2001\02\13@072610
by
Rodrigo Araujo Real
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
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

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

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

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

The routines in AN617 are simply integer routines, not fixed point.
If you have troubles with multibyte 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_OUTrodrigoTakeThisOuTFREEDOM.IND.BR>
Sent: Tuesday, February 13, 2001 14:17:32
To: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU
Subj: Fixed Point Arithmetic
{Quote hidden}> 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@235159
by
Scott Dattalo

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
o88591?Q?K=FCbek_Tony?=

Hi,
Nikolai wrote: ( spelling correct now :) )
>The routines in AN617 are simply integer routines, not fixed point.
>If you have troubles with multibyte 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
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: tony.kubekKILLspamflintab.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
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

part 1 1407 bytes contenttype:text/plain; charset=usascii
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 <.....rodrigoKILLspam.....FREEDOM.IND.BR>KILLspam.....MITVMA.MIT.EDU>
>
image moved 16/02/2001 11:39
to file:
pic03276.pcx)
Please respond to pic microcontroller discussion list
<EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU>
Sent by: pic microcontroller discussion list <PICLISTspam_OUTMITVMA.MIT.EDU>
To: @spam@PICLISTKILLspamMITVMA.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 contenttype:application/octetstream; (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

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.kubekKILLspamFLINTAB.COM>
Sent: Friday, February 16, 2001 11:54:43
To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU
Subj: [PIC]: Fixed Point Arithmetic
{Quote hidden}> Hi,
> Nikolai wrote: ( spelling correct now :) )
>>The routines in AN617 are simply integer routines, not fixed point.
>>If you have troubles with multibyte 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
> ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
> Email:
spamBeGonetony.kubekspamBeGoneflintab.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\17@120538
by
Olin Lathrop
> 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) 7723129, TakeThisOuTolinEraseMEspam_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
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}> > 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) 7723129,
RemoveMEolinTakeThisOuTembedinc.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

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

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* fixedpoint 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 willynilly, so you have to check the numbers before (almost)
every operation. Even "changesign" 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"
speffEraseME.....interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited>The AVRgcc 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
> 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
> 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) 7723129, EraseMEolinembedinc.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

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_piclistEraseMEEraseMEEMBEDINC.COM>
Sent: Saturday, February 17, 2001 16:37:04
To: RemoveMEPICLISTspam_OUTKILLspamMITVMA.MIT.EDU
Subj: [PIC]: Fixed Point Arithmetic
{Quote hidden}>> 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) 7723129,
RemoveMEolinTakeThisOuTspamembedinc.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.
2001\02\18@120505
by
Olin Lathrop
> 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
resourcelimited 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
resourcelimited 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) 7723129, EraseMEolinspamspamBeGoneembedinc.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

> ... 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
> resourcelimited 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
RemoveMEwalterKILLspambytecraft.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
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"
speffSTOPspamspam_OUTinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited>The AVRgcc 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

>
> 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
> resourcelimited 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
> resourcelimited systems.
It is possible to design a set of fixed point classes with C++ which
automagically handle scaling issues. It is nontrivial 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, lowlevel
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

 Original Message 
From: Spehro Pefhany <spamBeGonespeffSTOPspamEraseMEINTERLOG.COM>
To: <KILLspamPICLISTspamBeGoneMITVMA.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, lowlevel
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
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.1591989) was released.
Best regards,
=======================================
Spehro Pefhany "it's the network..." "The Journey is the reward"
EraseMEspeffEraseMEinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited>The AVRgcc 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
> >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.1591989) 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, lowlevel
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

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@spam_OUTinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited>The AVRgcc 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
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
spamBeGonewalterKILLspambytecraft.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
> 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, lowlevel
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
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

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_OUTinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited>The AVRgcc 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
> 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) 7723129, TakeThisOuTolin.....TakeThisOuTembedinc.com, http://www.embedinc.com

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body
2001\02\19@055345
by
Bill Westfield
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 resourcelimited 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 .....listservRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body
2001\02\19@061010
by
Vasile Surducan

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}> 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 resourcelimited 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
RemoveMElistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body
>
>

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistserv@spam@spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
2001\02\19@061425
by
Bond Peter Spetbond1
2001\02\19@070315
by
mike
>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 24bit '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 listservEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
2001\02\19@111941
by
Don Hyde

Do you have or know of a source of example code for good fixedpoint
routines for PIC's?
Do you know of a good textbook that discusses fixedpoint 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 fixedpoint 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 halfadders
and fulladders, mentions that that you COULD do fixedpoint arithmetic, and
then goes on about how REAL computers have floatingpoint units, and into a
discussion on how to build a floatingpoint unit.
SNIP
> I don't know about yours, but *my* fixedpoint routines are
> different thusly
>
SNIP
> ===============================
> ========
> Spehro Pefhany "it's the network..." "The
> Journey is the reward"
> RemoveMEspeffEraseMEspam_OUTinterlog.com Info for manufacturers:

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservRemoveMEEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
2001\02\19@124156
by
Spehro Pefhany

At 10:20 AM 2/19/01 0600, you wrote:
>Do you know of a good textbook that discusses fixedpoint 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 fixedpoint 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 floatingpoint 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"
EraseMEspeff@spam@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited>The AVRgcc FAQ is at: http://www.bluecollarlinux.com
=======================================

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservspam_OUT.....mitvma.mit.edu with SET PICList DIGEST in the body
2001\02\19@235300
by
Nikolai Golovchenko

There is a fixedpoint 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 <spamBeGonespeffEraseMEINTERLOG.COM>
Sent: Monday, February 19, 2001 19:43:59
To: PICLISTspamBeGoneMITVMA.MIT.EDU
Subj: [PIC]: Fixed Point Arithmetic
{Quote hidden}> At 10:20 AM 2/19/01 0600, you wrote:
>>Do you know of a good textbook that discusses fixedpoint 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 fixedpoint 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 floatingpoint 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"
>
RemoveMEspeff@spam@spamBeGoneinterlog.com Info for manufacturers:
http://www.trexon.com
> Embedded software/hardware/analog Info for designers:
http://www.speff.com
> Contributions invited>The AVRgcc FAQ is at:
http://www.bluecollarlinux.com
> =======================================
> 
>
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email
.....listserv@spam@EraseMEmitvma.mit.edu with SET PICList DIGEST in the body

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body
More... (looser matching)
 Last day of these posts
 In 2001
, 2002 only
 Today
 New search...