Reply by Bernhard Holzmayer●September 9, 20042004-09-09
Steve Underwood wrote:
> Actually, a number of languages used to support scaled fixed
> point. It used to be in most languages aimed at technical uses,
> like defence and telecoms. It seems to have gone out of fashion,
> though. I can't think of any currently popular language which
> supports it. Ada maybe (it is popular in defence circles)? I can't
> remember any of the Ada I learned years ago.
>
> Regards,
> Steve
>
Are you aware of the similarities between Ada and VHDL?
I guess if we talk fixed point and embedded systems, we're close to
talking the language of FPGA designers, and that is VHDL.
I see a trend to do more and more stuff in FPGAs instead of DSPs,
usually either because they're faster or because they can be adapted
better to the task, or just, because they're in place already.
If others do it the same way, there'll be less need for fixed point
support in other languages.
Bernhard
Reply by Jerry Avins●September 8, 20042004-09-08
Randy Yates wrote:
> Jerry Avins <jya@ieee.org> writes:
>
>
>>Randy Yates wrote:
>>
>>
>>>Steve Underwood <steveu@dis.org> writes:
>>>
>>>
>>>>[...]
>>>>I can't think of any currently popular language which supports it.
>>>
>>>C++, if you write your own classes, complete with overloaded
>>>operators.
>>>Problem is, the language is a bit fat for resource-starved embedded
>>>systems (we're still working with 8K of RAM!).
>>
>>Check out http://forth.com/embedded/trial-system.html
>
>
> From what I remember of Forth, it was assembly in reverse polish
> notation. Why not just learn assembly?
Forth is a lot more powerful than assembly. Some people call it a
scripting language because of its ease of use. Others belittle it as a
glorified macro assembler. It is what it is, and trying to peg it to one
thing is much like the blind men describing the elephant. One thing it
isn't is a marketable skill, but many turnkey houses that use it don't
say so. When you have a good thing going, why encourage others to share?
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Randy Yates●September 8, 20042004-09-08
Jerry Avins <jya@ieee.org> writes:
> Randy Yates wrote:
>
>> Steve Underwood <steveu@dis.org> writes:
>>
>>>[...]
>>>I can't think of any currently popular language which supports it.
>> C++, if you write your own classes, complete with overloaded
>> operators.
>> Problem is, the language is a bit fat for resource-starved embedded
>> systems (we're still working with 8K of RAM!).
>
> Check out http://forth.com/embedded/trial-system.html
From what I remember of Forth, it was assembly in reverse polish
notation. Why not just learn assembly?
--
% Randy Yates % "Though you ride on the wheels of tomorrow,
%% Fuquay-Varina, NC % you still wander the fields of your
%%% 919-577-9882 % sorrow."
%%%% <yates@ieee.org> % '21st Century Man', *Time*, ELO
http://home.earthlink.net/~yatescr
Reply by Jerry Avins●September 8, 20042004-09-08
Randy Yates wrote:
> Steve Underwood <steveu@dis.org> writes:
>
>>[...]
>>I can't think of any currently popular language which supports it.
>
>
> C++, if you write your own classes, complete with overloaded operators.
> Problem is, the language is a bit fat for resource-starved embedded
> systems (we're still working with 8K of RAM!).
Check out http://forth.com/embedded/trial-system.html
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Randy Yates●September 8, 20042004-09-08
Steve Underwood <steveu@dis.org> writes:
> [...]
> I can't think of any currently popular language which supports it.
C++, if you write your own classes, complete with overloaded operators.
Problem is, the language is a bit fat for resource-starved embedded
systems (we're still working with 8K of RAM!).
--
% Randy Yates % "Midnight, on the water...
%% Fuquay-Varina, NC % I saw... the ocean's daughter."
%%% 919-577-9882 % 'Can't Get It Out Of My Head'
%%%% <yates@ieee.org> % *El Dorado*, Electric Light Orchestra
http://home.earthlink.net/~yatescr
Reply by Jerry Avins●September 7, 20042004-09-07
Steve Underwood wrote:
> glen herrmannsfeldt wrote:
>
>>
>>
>> Jerry Avins wrote:
>>
>>> When taking Randy's suggestion, you will do well to rid yourself of
>>> some misconceptions.
>>
>>
>>
>>> Overflow can happen always when adding, and except for the Q format
>>> that represents all numbers as smaller than one, when multiplying.
>>
>>
>>
>> If the product form is the same as the multiplier and multiplicand, yes.
>>
>> Most processors multiply two N bit numbers generating a 2N bit
>> product that cannot overflow. If one uses only some of the product
>> bits, not including the most significant bit, then it might overflow.
>>
>> PL/I is one of the few high level languages with provision for scaled
>> fixed point (either binary or decimal) numbers. Each variable can
>> have its own scale factor.
>>
>> With the appropriate number of bits for the sum, it can't overflow
>> either.
>>
>> -- glen
>>
> Actually, a number of languages used to support scaled fixed point. It
> used to be in most languages aimed at technical uses, like defence and
> telecoms. It seems to have gone out of fashion, though. I can't think of
> any currently popular language which supports it. Ada maybe (it is
> popular in defence circles)? I can't remember any of the Ada I learned
> years ago.
>
> Regards,
> Steve
Several Forth packages intended for embedded systems. All Forths have a
scaling operator, and some have more extensive suppport.
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Steve Underwood●September 7, 20042004-09-07
glen herrmannsfeldt wrote:
>
>
> Jerry Avins wrote:
>
>> When taking Randy's suggestion, you will do well to rid yourself of
>> some misconceptions.
>
>
>> Overflow can happen always when adding, and except for the Q format
>> that represents all numbers as smaller than one, when multiplying.
>
>
> If the product form is the same as the multiplier and multiplicand, yes.
>
> Most processors multiply two N bit numbers generating a 2N bit
> product that cannot overflow. If one uses only some of the product
> bits, not including the most significant bit, then it might overflow.
>
> PL/I is one of the few high level languages with provision for scaled
> fixed point (either binary or decimal) numbers. Each variable can
> have its own scale factor.
>
> With the appropriate number of bits for the sum, it can't overflow
> either.
>
> -- glen
>
Actually, a number of languages used to support scaled fixed point. It
used to be in most languages aimed at technical uses, like defence and
telecoms. It seems to have gone out of fashion, though. I can't think of
any currently popular language which supports it. Ada maybe (it is
popular in defence circles)? I can't remember any of the Ada I learned
years ago.
Regards,
Steve
Reply by glen herrmannsfeldt●September 7, 20042004-09-07
Jerry Avins wrote:
> When taking Randy's suggestion, you will do well to rid yourself of some
> misconceptions.
> Overflow can happen always when adding, and except for the Q format that
> represents all numbers as smaller than one, when multiplying.
If the product form is the same as the multiplier and multiplicand, yes.
Most processors multiply two N bit numbers generating a 2N bit
product that cannot overflow. If one uses only some of the product
bits, not including the most significant bit, then it might overflow.
PL/I is one of the few high level languages with provision for scaled
fixed point (either binary or decimal) numbers. Each variable can
have its own scale factor.
With the appropriate number of bits for the sum, it can't overflow either.
-- glen
Reply by Brad Griffis●September 4, 20042004-09-04
"ranjeet" <ranjeet.gupta@gmail.com> wrote in message
news:77c88a3b.0409030108.19b9f2aa@posting.google.com...
> Hi all !!!!
>
> As we all know that In fixed point it is easier to multiply the
> numbers of the same Q format but their is difficulties in the addition
> of this.... correct.
>
> So my question comes like this. As we go for the basic knowledge. we
> realise that the mutilipcation is nothing but simple addition........
> right.
>
> now if we gor for the mutilication then we mean that their is lot of
> addtion as compared to the simple addtion of the same number.
>
> so why it has been said that multiplication is simple as compared to
> the addtion.
I believe that what you are thinking of here is that it is easier to
multiply to 16-bit Q15 numbers together than it is to add them. The reason
for that is because a Q15 number is bound to [-1,1). Therefore when you do
a multiply you remain within those bounds but if you add you may overflow.
Brad
Reply by Tim Wescott●September 3, 20042004-09-03
Jerry Avins wrote:
>
> Floating-point addition in software takes longer than floating-poing
> multiplication in software on those processors that can multiply signed
> integers as fast as they can add them.
>
> Ignoring the conditions can lead one to Ranjeet's erroneous conclusion.
>
> Jerry
Unless the processor also has a way-fast normalization instruction. I
was _very_ surprised at the speed of floating point on the TMS320F28xx
processor with Code Composter. At the place I used to work I had a
fixed-point arithmetic library. It has saturating adds and fractional
multiply to slow it down, and it was just about as fast as floating
point on the 'F28xx -- on anything else floating point was way slower,
even on a Pentium with fast floating point (no, I never tried it on a FP
DSP).
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com