avr-gcc Feature: Fixed-Point Support

Go To Last Post
30 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

F'up of avr-gcc: New Features?

gchapman wrote:
More of Embedded C.
IIRC, avr-gcc 4.8 will (has) restore(d) fixed point; is that correct?

Well, I never saw anybody actually using fixed-point with avr-gcc. (The commonly used Atmel port has support for this.)

If programmers would use it, they would come up with questions (they come up with questions for everything they use), but I never saw even a single question "” neither here nor in the leading German µC forum.

There is actually one question, but it is one of my own few questions...

The fixed-point support in avr-gcc 4.8 will not be binary compatible to the Atmel support.

The support is still in draft state and there are many, many corners that need to be worked out. It's already clear that the support will not be complete by the time avr-gcc will be released (around march, I guess).

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problems of inertia and Catch-22.
Fixed point arithmetic is fairly new to C versus other languages so usage should lag capability.
I'm glad there is now a standard for this in C and at least some implementations of it.
Thanks for working on this and much more!

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should play with the available fixed-point support as I do quite a bit of implementing fixed-point routines manually. I haven't had a time where I felt that the time required to find the bugs in a new implementation were worth the cleaner syntax... but I would use it if it were there and solid. As gchapman says, Catch-22: it's hard to justify "play time" but the results could be extremely productive.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FP is an interesting domain for DSP applications. Though a FP math lib is also required. Could be fun for example to able to build the speex AEC (I han't really tried it)

But usually, in FLOSS, as soon as FP get close to the application domain the track goes really cold.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oloftangrot wrote:
Could be fun for example to able to build the speex AEC (I han't really tried it)
fyi, the Speex codec has undergone obsolescence.
Opus has fixed point.
This could be a practical early use of Embedded C fixed point for AVR by extending Opus to use that (in addition to its current fixed point).
Ref.:
https://wiki.xiph.org/OpusFAQ#Is_there_a_fixed-point_implementation.3F

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely such algorithms have to encode and decode in real-time? Can anyone really see a 20MHz AVR managing that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes and yes (for decode).
For Speex, the long pole is encoding.
A spec large XMEGA might be able to keep up with Speex narrow-band encoding; over-clocking may need to be considered.
Haven't estimated the numbers for Opus.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, once again we have the classical deadlock:

• It's not mature => I won't use it
• Feature is unused => It won't mature because of missing feedback

I don't say anybody should drive tests, the GCC testsuite have tests for it and provide a reasonable coverage.

But just like with any other product on this planet: Without user's feadback, it cannot be improve further.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Appears Opus on AVR may be a good library.
But first would be Opus using Embedded C.
Would you know which GCC would be "mature" for Embedded C fixed point?
I assume either x86 or ARM.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I don't know. AFAIK x86 does not support fixed point. arm-gcc supports it but I cannot say anything about how stable it is, how widespred is its use, and how complete the library support (string conversion etc.) is.

For avr-gcc there is currently avr-atmel-gcc-4.6.2+ and avr-gcc 4.8+ (experimental). The 4.8 release has some problems fixed compared to the Atmel approch and some better optimizations (which might have introduced bugs) and it uses a different fixed-point layout (allows less optimizations and again, bugs may result).

I also played around with stuff that is not mentioned in the Embedded-C paper, namely sin, arcsin and sqrt for the s16.15 type (signed accum).

It's not easy to be afficient and control the rounding errors, in particular for values that are close to the singularities of arcsin (solved by cubic lookup and reducing arcsin to a square root).

Moreover there is a solution to the "representation problem": If you want to stringify, say s.15, then you don't want to use the next wider mode (32-bit arithmetic in this case) to get the string representation. This is clear because at some point there is no more a wider mode. Moreover, wider modes are (much) less efficient.

The current state of the implementation in mainline avr-gcc is:

Base arithmetic: =, +, - (unary and binary), *, /, comparisons, conversions and the bitsfx and fxbits bit banging functions, functions to compute the absolute value.

Some of these are optimized and / or provided as assembler routines, others are provided by open coded C from generic libgcc.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Well, once again we have the classical deadlock...

True. I wish I actually had time to do some test driving, but I barely have time, at the moment, to get any programming done with the systems I already have in place. What I can probably do is to look through the current support and see if it would meet my needs ( be useful ) and comment on why or why not.

Most of the uses I have for fixed-point values are in the robotic control systems. The control loop closure rate is important, which is why I avoid floating point, but I still need fairly high resolution in calculation... hence fixed-point. One feature that I do take advantage of quite a bit in my own code, is the ability to adjust the fixed-point format on an almost per value basis. That is something I know I will dearly miss -- but it would very likely be worth it for reduced code complexity.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But just like with any other product on this planet: Without user's feadback, it cannot be improve further.

Surely a "good feature" (like __flash) is going to attract lots of users/feedback because lots of people want to use it. With something like fixed-point it's a bit "niche" and while the implementer clearly saw a need I'm not sure many other users will (with the possible exception of Martin ;-))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
arm-gcc supports it but ...
That's OK (looking for an alternate implementation to bounce against).
SprinterSB wrote:
The current state of the implementation in mainline avr-gcc is: ...
Again, Thank You!

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
With something like fixed-point it's a bit "niche" and while the implementer clearly saw a need I'm not sure many other users will
I think it's the best to discuss with the maintainers to clean up the backend from that code and dismantle the fixed-point stuff.

Hand-written fixed-point has clearly the advantage that the user can put the decimal point at any place and need not to rely on some technical report that is not adopted by the standard.

It makes avr-gcc more complicated; the compiler tries to produced optimized code for not less than 500 conversion routines alone...

It's pointless to have that complexity of dead code. I'll talk to the maintainers so that I can finish the clean up before 4.8 is released so that it does not slip to user land.

And nobody complain in the future that floating point arithmetic on AVR is too slow or too memory gulping :-)

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darn.
Was hoping to see more of Embedded C available.
Context - I formerly used fixed point a lot in JOVIAL and Ada.
There is some use of AVR thru libfixmath.
Ref.:
Fixed-point arithmetic.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting that this should come up, because today I have come to realize that my current project would benefit greatly from some fixed-point math routines.

I'm working in degrees Kelvin, with T^4 terms in the algorithm which immediately puts me over a uint32_t. So I can't just scale the math and reduce it in the final step.

TI provides a fixed-point library and even a fixed-point engine for some of their DSP's.

Applications vary greatly, and sometimes a tool is only useful if it is readily available. One can't always go bigger, faster.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kmceng wrote:
TI provides a fixed-point library and ...
For Atmel it's AVR32 UC3 and ASF's DSPLIB.
MCU/DSP makers creating optimized libraries for their products seems to be common.
I was hoping for C to eventually have this closer to a common way to implement fixed point for a portability reason.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right. And the AVR32 I last used even had a floating point processor.

But this project is on an Xmega128. It doesn't need much speed, but the math just happens to be BIG. Guess I'll look into using long long.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree that removal from the compiler is justified. It's not difficult to do an implementation by hand, it is more flexible, and, if it is a hindrance to producing a robust compiler -- I see very few advantages in the absence of such fixed-point support being mandated by the standard.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, __flash also destabilizes and is non-standard. Thus throw it out, too.

And the initial xmega support in 4.7.0 was completely broken. Should it be removed?

Stability is important but without changes avr-gcc is dead. I initially started contributing to avr-gcc because it accumulated more and more bugs and more and more optimization flaws.

I think it's still better to destabilize and fix problems in a timely matter than to accumulate more and more problems and do nothing about it and let it die.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kmceng wrote:
But this project is on an Xmega128. It doesn't need much speed, but the math just happens to be BIG.
From libfixmath, it's interesting that sometimes fixed point applications are smaller and/or faster than floating point.
kmceng wrote:
Guess I'll look into using long long.
Worked on one application where the BIG math was only for one equation so used floating point for only that equation; otherwise the application used fixed point.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I has a look at the libfixmath. My impression:

The project is live: I files who issues yesterday (with proposed patch) and they are already fixed.

The sources support some static confugury like FIXMATH_OPTIMIZE_8BIT (recommended for AVR) or FIXMATH_NO_64BIT.

A s15.16 (called fix16_t there) multiplication takes more than 700 bytes, not taking into account size of the callees (it's no leaf function).

The GCC equivalent needs ~120 bytes and no calls.

Saturated addition in libfixmath takes > 120 instructions. GCC perform it inline in 10 or 11 instructions (depending on constness off addend).

There is definitely room for improvement. For example, libfixmath could pick up an existing intrinsic fixed-point support and build atop of it. It's possible to query GCC whether or not the support is available and how the fixed-point layout looks exactly.

The size of mul is really big. I have no sizes for float mul from AVR-LibC handy, but I think it's less consuming.

However, there is also room for improvment in libgcc's open coded fixed-point parts, namely saturated addition, multiplication and 64-bit types.

BTW, with the float support from AVR-LibC you can even

No assembler hacks, all Standard-C99 as provided by the tools, including float arithmetic! (Some non-standard headers like avr/io.h were used to get the digits via UART out of the µC).

One advantage of the embedded fixed-point support is that it looks like ordinary C. Operations and constants are not opfuscated by functions or macros. If you want 1.25*x, just write 1.25r * x. That's it.

Notice that C++ does not allow you to define new suffixes, and yo cannot put non-POD classes (anything that is more than a struct or union in C) into flash. Thus, with C++ you cannot use lookop tables or constructors for constants. You need ugly macros etc.

IMO, the interesting part of Embedded-C is that it covers spots that can't be covered nicely by C++. (Adress spaces is one more example).

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for evaluating libfixmath.

SprinterSB wrote:
The GCC equivalent needs ~120 bytes and no calls.
...
One advantage of the embedded fixed-point support is that it looks like ordinary C.
Fixed point arithmetic is essential and having a "standard" way to have it in C is excellent.
Atmel needs to contract with you to add fixed point to avr-gcc; even it's only from Atmel for awhile it'll still be a selling point for Atmel to have Embedded C.
Otherwise, I hope you keep your work on a back burner.

C++ - wasn't aware of those points. Thanks!

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:

 

Well, I never saw anybody actually using fixed-point with avr-gcc ...

 

 

If programmers would use it, they would come up with questions ...

 

 

It's probably a bit late in the day to add our experiences to this or hold our hand up ...

 

But we use this ! ... and with a bit of independent thought we made it work without recourse to pestering you good folk to do our thinking/work for us.

 

For the record we've always taken the policy of being ultra-cautious and staying on the last stable/production version of the tool chain and have been on WinAVR-20100110 for what seems an eternity. The addition of the fixed point to later versions of GCC moved us to a more recent build (WinAVR-20141209) (see two posts down for a correction/explanation of this statement) which has now become our preferred solution.

 

The project was accelerometer based and needed a flexible approach to calibration and maths to resolve its needs ... floating point was both too slow and too large for the end application (although we did use it for proof of concept and algorithm debugging) and so were faced with either migrating to the later GCC or creating our own fixed point routines.

 

GCC offers sufficient for what we need so we chose that route ... and were able to make use of the __flash features ... and int24 ... as well as a side effect.

 

Many thanks for making it possible!

 

Mike

Last Edited: Sat. Jan 10, 2015 - 04:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since when has there been a 2014 version of WINAVR? I just checked sourceforge and 2010 was the last issue. 

 

http://sourceforge.net/projects/...

Last Edited: Sat. Jan 10, 2015 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're absolutely correct ... it was my bad/loose explanation of what we did that's led to the confusion ...

 

2010 is, as far as we have been aware, the latest version of the WinAVR tool chain, and that's the one that, until recently, we have been using. As I say, we tend to lean on the cautious side and have always stuck with the most stable, most well known and most well supported of things as far as possible.

 

When we came to this particular project though we were faced with a choice ... the 2010 version of WinAVR has GCC version 4.3.3 within it ... we could either, write our own Fixed Point functions and compile under 4.3.3, or move off the official, latest release based on 4.3.3 to something else based on a more recent version of GCC which contained fixed point within it at the language level rather than the function level that our implementation would have had.

 

We searched around ... and I can't reconstruct the sequence exactly but we ended up at the following link http://sourceforge.net/projects/... and that's where we picked up the version that I referred to earlier. For consistency with our own internal version number checking scripts etc. I renamed the final target directory to WinAVR-20141209 and that probably completed the confusion.

 

Of course that means that we are completely off the normal support/maintenance line and out in the cold!

 

Sorry for any confusion ...

 

Mike

 

Last Edited: Sat. Jan 10, 2015 - 04:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LordAdam wrote:

 but we ended up at the following link http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/ and that's where we picked up the version that I referred to earlier.

 

Probably not the worst implementation you could find.

 

It says : Brought to you by: sprintersb

 

/Bingo

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well it was more by luck than judgement that we ended up there ... looking back at it I think we were generally reading up postings on Fixed Point ... that led to SprinterSB's comments etc and that led to the link. He'd obviously had a significant amount to do with fixed point (and there I suspect I show my ignorance and naivety) so we felt reasonably comfortable giving it a whirl.

 

As I said, we normally stay very much in the mainstream ... but now that we are away from the traditional base of 2010 is there a 'proper' place that we should go or monitor for the later releases of the toolchain?

 

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LordAdam wrote:
As I said, we normally stay very much in the mainstream ... but now that we are away from the traditional base of 2010 is there a 'proper' place that we should go or monitor for the later releases of the toolchain?

http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx

http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A beta Arduino has an Atmel patch set.

Some Arduino teammates and third parties have moved to or added the beta Arduino IDE.

Ref.

Arduino

Arduino Software Release Notes

http://arduino.cc/en/Main/ReleaseNotes

ARDUINO 1.5.7 BETA - 2014.07.07

[core]
* Upgraded AVR toolchain: gcc 4.8.1, avr-libc 1.8.0

GitHub

arduino/toolchain-avr at atmel-3.4.4

https://github.com/arduino/toolchain-avr/tree/atmel-3.4.4

"Dare to be naïve." - Buckminster Fuller