If you run it, it will hit abort. Reason is a pasto in __fractuhasf, cf. this patch against 4.5.1 for example. The tool chain is patched against 4.6.2 as you can see in the previous post, but the typo is still there.

Even when linking with -lm the float routines from libgcc are used instead of the hand-optimized routines from AVR-Libc. Reason in that __fract[u]{q|h|s]}{a|q}sf from the patch refer to float routines and the linker resolves them in libgcc, not in AVR-Libc.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Unfortunately there are more problems: __fractsfhq and __fractsfqq are also wrong, they convert from float to fract resp. to short fract.

I am currently attempting to port the fixed-point support to avr-gcc 4.8 and thought that because the code was releases in several distributions, it has experienced some review, testing and increased reliability by means of every-day use by tool chain users.

So it's more work than just adapting the sources because the patches are pretty much outdated as avr-gcc evolves.

It's would be a pity if Sean's work would rot that way, but I also feeling stupid from time to time to do Atmel's home work...

Does anyone use built-in fixed-point arithmetic at all? It appears I am just adding thousands of lines of dead code to the compiler, just rendering it bigger, more complicated and less stable...

Johann! I am a potential user of fixed-point, but have not yet adopted it.

Yes, it would be a shame if Sean's work was to rot away.

I am not in a position, ignorance and lack of time, to do development on this stuff. Testing might be another matter. Is there any infrastructure in GCC to set up and automate tests?

I could go looking for it myself, but a himt/spoiler would help.

I consider myself quite a seasoned C programmer, but one thing that is still both mystical, magical and very scary is the inner workings of GCC, and stuff like the "auto-tools", "configure", patching etc. I have considered trying to build avr-gcc myself, just for the fun of it, but always becomes overwhelmed by the amount of things I do not know/understand. You have my deepest admiration.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

GCC comes with its own testsuite that needs the DejaGNU harness. A convenient way to run execution test is the avrtest hosted with WinAVR, see the README.

The fixed point tests are located in gcc.dg/fixed-point. The only problem there is convert.c which is much tooo big to be executed on ATmega128. Someone will have to split that test case into more manageable parts.

However, the main issue is not running these tests, it's mainly on source level. The sources badly need review and better comments. For example, the second problem mentioned above was triggered by code that originally read

It's much easier on that level than to run a 100k program that hits abort somewhere.

In order to test individual routines, I don't use the test suite harness because it is not easy to test a new implementation of, say 32-bit multiplication against an existing one. It's much more lightweight to factor out the routine(s) and test them in a small incubator environment like

That way everything is in a small, ordinary C/asm program. No test suite is needed, no GCC sources, no building GCC. Only after the algorithm performs well (code size, speed, correctness even in corner cases, proper coding style and source comments) it's integrated in GCC and run against the test suite.

Quote:

I consider myself quite a seasoned C programmer, but one thing that is still both mystical, magical and very scary is the inner workings of GCC, and stuff like the "auto-tools", "configure", patching etc. I have considered trying to build avr-gcc myself, just for the fun of it, but always becomes overwhelmed by the amount of things I do not know/understand.

Well; do you understand your computer? I don't understand my computer. I don't even understand a stone. I don't know enough of quantum physics to understand a stone, why it is solid, why it is brown or gray, why it is hard or soft. Yet I have a basic understanding of a stone and how I can handle it, how it feels like, what I can do with it and what not.

I don't even understand my conmputer on the transistor level. Give me a layout scheme of a computer with all it's transistors things, and I don't even know if it's a computer or modern art or tokio's subway. No Idea how all these transistors work together to make Clippy speak to me.

Thank you for the thorough post. I will read it again during weekend to see if I get the finer details of what you write, and ponder if I can contribute.

Me paying back to the avr-gcc community is way overdue, so if it is within my abilities and time I will have a go at it. E.g. the splitting up of tests might be feasible..

I see that the fixed-point tests are not AVR specific (I should have realized that from the start) but GNU-generic. This means that one could "harness" some stuff and test it on a Linux- or Windows-host as well as wellas for an AVR, and expect the same results down to the last bit, right?

Quote:

Well; do you understand your computer?

I understand it more than well enough to use it. (No-one really needs to know the inner workings of a full-adder in order to use a computer, but I still know (or knew) that. One of my all-time favourite books is Tannenbaums "Computer Architecture - a Structured Approach).

Re GCC I do not understand the things involved well enough to even talk about building the tool chain. As I said, every time I try to approach that subject I am overwhelmed.

A rock is solid because else you'd call it "lava".. :wink:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

I see that the fixed-point tests are not AVR specific (I should have realized that from the start) but GNU-generic. This means that one could "harness" some stuff and test it on a Linux- or Windows-host as well as for an AVR, and expect the same results down to the last bit, right?

No :-)

The fixed point widths are implementation defined, same for their integral and fractional parts. Same for overflow of the non-saturated operations (undefined, modular warp, saturate, ...). Same for the rounding (to zero, to +oo, to -oo, nearest, undefined). Same for the magnitude of the rounding error (within 2 Â±LSBs from the exact result, if I understand TR 18037 correctly).

And of course, only modulo bugs in the implementation. I broke convert.c apart and it can be executed now, but it does not pass so there are more bugs to fix...

Quote:

Re GCC I do not understand the things involved well enough to even talk about building the tool chain. As I said, every time I try to approach that subject I am overwhelmed.

Building is not too complicated; the build scripts around are just frightening scary. You just need a couple of commands, 60% of which are "make" or "make install". You don't need to be root, you don't need to sudo, ...

If you feel to ask questions, a mailing list like avr-gcc-list is a much more convenient place.

You can write % in the code without anyone getting a heart attack.

You can link to documentation or other helpful pieces of information without proving that you are human.

You can attach code without obfuscating it as zip or whatever.

You can quote without using BBcode or other weird stuff. Just quote.

You can download attachments without their MIME-type being messed up or browser pissed off.

You have real tree-like threads.

You can see text attachments like patches without downloading them and you can easily quote parts thereof to comment on it.

You can use your favourite e-mail program. No annoying advertisements, no blinking graphics, no annoying styles and designs, ...

It's focused on the AVR tools, not on developing with these tools, thus it's more appropriate for things below the surface.

No more ads. No more meaningless green goo occupying 40 percent of your browser.

Quote:

tree-like threads

Isn't that an oxymoron? :wink:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]