Re: New tool releases

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
dl8dtl wrote:
[*] An helper file, contributed by Cliff Lawson and
Carlos Lamas.

OMG! Fame at last - but will the new found celebrity mean that I can give up my day job?

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

My name's in there twice, does that mean I get Cliff's job? ;)

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Cliff, Dean,

It would be great if you both would be willing to help more. We could always use more help in fixing bugs. We're actively looking for someone to help with C++ issues, specifically for someone to try to build libstdc++. We're also looking for someone to add 64-bit double math routines. We could always use more help with GCC bugs as well, if not fixing them, then going through the known bugs and testing them to see if they still exist with recent versions. The list goes on... ;)

Eric

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

Ask again on the 21st (day after exams finish) and I'm all ears and eager to help. I'll be off Uni from the 21st of November to early March, and in that time apart from working on my own projects and finding some way of earing money, I'll be free to help out.

Not so sure how useful I would be at tracking down GCC bugs, it's a damn big compiler and I'd have no idea how the whole thing fits together...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Eric,

As someone who avoids C++ like the plague I think you can count me out of the libstdc++ work but I'm more than happy to look at some other issues.

As I've been looking at the source of various C compilers for AVR I'm more than happy to have a look at bug fixing and perhaps even the 64 bit math stuff as I've had dealings with IEE754 in the past

Is there a prioritised list of things to be "done"? Obviously it makes most sense to go for the biggies at the top of the list

Cliff

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

Unfortunately there is not a prioritized todo list. The best thing to do, I've found, is to find something that interests you or that you've always wanted to have. You can also ask Joerg or I about projects.

Another suggestion on things to do is documentation. Dean, I hear that there are a number of tutorials over on the tutorials forum. What are they doing there? Why not incorporate them into the official documentation, like in the avr-libc user manual? We could always use more help there. When a new user comes along, I'd much rather point to the documentation, and tell them to look there on how to do things.

Joerg and I highly suggest that you subscribe to the avr-libc-dev mailing list (at the avr-libc project) and talk about projects on that mailing list. All the AVR toolchain developers are subscribed to that list.

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

Quote:

Dean, I hear that there are a number of tutorials over on the tutorials forum. What are they doing there? Why not incorporate them into the official documentation, like in the avr-libc user manual?

This is a most excellent suggestion!

Yes, the documentation of avr-gcc, avr-libc etc should be as close to those things as possible. This should go for general tutorials also. And at least one of Deans tutorials are non-WinAVR-specific, but rather applies to avr-gcc/avr-libc generically (the PROGMEM tutorial, which is Real-Good-Stuff).

Yes, Dean is an excellent tech writer. He has or gets the facts correct, his language is good, the flow is lean, and he has "pedagogic ability" (which I have a hard time describing more specifically, but I think you know what I mean). IMHO he can contribute in no better way than in the documentation (which does not mean that other types of contribution from him would not be of the highest standard. On the contrary. It's just that good tech writers are not so easily found.)

And us oldies should be very proud of Dean - we taught him almost everything he knows... :wink: (Sorry Dean, not even close to true, but a pun that was impossible to resist!)

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]

Last Edited: Wed. Oct 31, 2007 - 08:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I was driving home tonight thinking "I wonder exactly what's involved in implementing 64 bit floats". Is this kind of thing actually documented somewhere to say which routines need to be provide in 64 bit variant and what the ABI is?

Cliff

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

> My name's in there twice, does that mean I get Cliff's job? ;)

But you're lacking the "10k+ superfreak" capture. ;-)

I'd like to thank you again for re-submitting the modified
interrupt.h file in a very timely fashion, Dean.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

> Well I was driving home tonight thinking "I wonder exactly what's
> involved in implementing 64 bit floats". Is this kind of thing
> actually documented somewhere to say which routines need to be
> provide in 64 bit variant and what the ABI is?

There's basically two things (or three) involved here.

First is to teach the compiler about 64-bit floating-point numbers.
In GCC's terms, that would be "DF" numbers (double-precision
floating-point), so far only "SF" number handling is implemented.

This is mostly (?) done in the file gcc/config/avr/avr.md, the
so-called machine description.

When implemented, I'd like to see it enabled by default, but also have
an option similar to the existing -mint8 option (say, -mdouble32).
The reason to have 64-bit doubles by default is that the C99 standard
essentially requires it to be that way, i. e. we are currently not
compliant to the C standard. However, as most users probably wouldn't
want it to be that way, we could then simply add the -mdouble32 option
to all the Makefile templates as a useful default. Ideally, even with
-mdouble32, the "long double" type could still be 64 bits anyway.

The second part is to implement trigonometrical etc. functions for
64-bit floating-point numbers, i. e. establish the counterpart to the
existing libm.a. We have to modify avr-libc's build system a bit
then, and hopefully, the selection of the correct libm.a could even be
automated provided the -mdouble32 option is also passed to the
compiler when calling the linker. Decisions like these are made in
the compiler in the so-called "specs", which could be located in an
external file. (There's a compiled-in copy of the specs as well.)

Finally, it might be useful to hand-optimize some basic arithmetic
functions for libgcc.a. As we can already see with 32-bit and 64-bit
integer arithmetic, the default (automatically generated) library
functions are often rather bloated.

And no, as we don't have 64-bit FP numbers so far, there's no ABI yet.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:

Dean, I hear that there are a number of tutorials over on the tutorials forum.

You've never looked? I'm heartbroken!

I certainly have no objections to having one or more of my tutorials incorporated into the GCC documentation - the more visibility the better (and the better my resume will look).

I like to work with both code and documentation (but not both at the same time, having to add Doxygen comments to my patches for GCC was torture and a half) so I'll go where needed and do what's wanted after my exams. Consider me an able and willing body to do what I can after the 20th.

Quote:

And us oldies should be very proud of Dean - we taught him almost everything he knows...

And I thank you all for it. Smokey's book taught me C, you guys taught me far more than any book could have (sorry Smokey! ;)). Contributing here has helped me cement my own knowledge, as has reading other responses too.

Quote:

I'd like to thank you again for re-submitting the modified
interrupt.h file in a very timely fashion, Dean.

No problem. Far more interesting than studying the procedure to solve Second Order Linear Differential Equations! That, and I *really* wanted to see my work being put into the mainline and by extension general use...

Note that my articles in the Tutorials forum about the Atomic and new Interrupt macros are now essentially invalid, since the code's now in the avr-lib-c mainline. I'll add a note in the relevant articles once the code is in the next WinAVR (but keep them for discussions and those using older WinAVR releases).

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

> I like to work with both code and documentation (but not both at the
> same time, having to add Doxygen comments to my patches for GCC was
> torture and a half) [...]

Oh well. Great that you supplied the reference documentation for your
stuff! I only made very minor changes to it. I added some examples
to the doc/api/interrupt.dox file which forms the introductionary
paragraphs to the interrupt API, and is supposed to go somewhat beyond
a plain reference manual.

Doxygen might not appear to be the best thing on earth, but let's face
it, before we included the doxygen documentation into the sources,
avr-libc suffered from a notorious lack of documentation, and has
essentially been "hacker's ware" by its time. There have been
attempts to provide 3rd-party documentation, like Rich Neswold's docs
which we were then allowed to incorporate, but projects like this one
have a tendency to always lack behind the current state. The
availability of a (matching) reference and user documentation has IMHO
drastically improved the usability of avr-libc.

> No problem. Far more interesting than studying the procedure to
> solve Second Order Linear Differential Equations! That, and I
> *really* wanted to see my work being put into the mainline and by
> extension general use...

Oh, I once have been pretty good in solving differential equations,
too. ;-) But that's arguably been quite a while ago. If I neeed to
solve them today, well, I'd have to find a way to recover that old
knowledge.

Whether or not the next version of WinAVR will already incorporate the
new header files or not basically depends on Eric's decision about
using either avr-libc 1.4.7 (or perhaps 1.4.8), or whether the testing
results for 1.5.1.20071029 indicate that rolling a 1.6.0 release will
be fine. In particular the deprecation of ISR_ALIAS() in favour of
the ISR_ALIASOF() attribute to ISR() is something that won't be merged
back into the stable (1.4.x) branch.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:

Oh well. Great that you supplied the reference documentation for your
stuff! I only made very minor changes to it. I added some examples
to the doc/api/interrupt.dox file which forms the introductionary
paragraphs to the interrupt API, and is supposed to go somewhat beyond
a plain reference manual.

I can certainly see the utility of the DoxyGen comments - I had to use JavaDoc to document my Java assignment a few weeks ago. JavaDoc is nice in that the resulting code comments are easy to read in the source as well as the output, while I find DoxyGen's syntax annoying and esoteric for some indefinable reason. It's probably partly due to the presence of the C preprocessor which requires all the #if defined(DOXYGEN) garbage littering the code.

Quote:

In particular the deprecation of ISR_ALIAS() in favour of
the ISR_ALIASOF() attribute to ISR() is something that won't be merged
back into the stable (1.4.x) branch.

I've never understood how that works. Does that mean that the ISR_ALIASOF() attribute will be thrown out eventually? Or will it be an alternative indefinitely? Removing it reduces the utility of the new macro, and negates the point of having a common syntax for all ISR types in the first place.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Just in case anyone starts writing 64-bit float. I think this bug should be solved first.

And I personally think implementing something like Bjoern Haasse has proposed here is a much greater win.
Making all of his patch work might be a bit too much at once.
But implementing the and, or, xor as define_expand should not be much work and the gain is considerable.

Just consider this "invert-the-middle-bytes-in-a-u32" function:

 unsigned long foo(unsigned long in) {
    return in^0x00FFFF00;
}

This will bloat to:

	mov r18,r22	 ;  6	*movsi/1	[length = 4]
	mov r19,r23
	mov r20,r24
	mov r21,r25
	ldi r22,lo8(16776960)	 ;  11	*movsi/5	[length = 4]
	ldi r23,hi8(16776960)
	ldi r24,hlo8(16776960)
	ldi r25,hhi8(16776960)
	eor r22,r18	 ;  12	xorsi3	[length = 4]
	eor r23,r19
	eor r24,r20
	eor r25,r21

While it could be something like:

   com 23
   com 24

Now that's what I call a considerable gain!

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

> I can certainly see the utility of the DoxyGen comments - I had to
> use JavaDoc to document my Java assignment a few weeks ago. JavaDoc
> is nice in that the resulting code comments are easy to read in the
> source as well as the output, while I find DoxyGen's syntax annoying
> and esoteric for some indefinable reason.

Well, doxygen's syntax isn't that much of a problem. It's more that
its behaviour has been tuned for documenting an entire project (in the
sense of internal documentation that could later be used by fellow
workers on the same project), rather than providing public
documentation for a library that ships (sort of) as a "blackbox"
approach.

> It's probably partly due to the presence of the C preprocessor which
> requires all the #if defined(DOXYGEN) garbage littering the code.

This is not strictly necessary to make doxygen work. However, that's
to mitigate some of doxygen's behaviour as explained above. Normally,
doxygen would not only add documentation for a particular macro but
also add the entire *implementation* into the documentation. In the
case of avr-libc, this would mean that all the hairy details about the
internals of the macro (often ending up in hard to grasp but
well-working inline assembly code) would be thrown onto the poor
user's head -- where the user doesn't gain anything by this, as he
could simply handle the macro as a blackbox that just does the job he
wants it to do. If he's really interested in learning *how* the stuff
works, he can always look into the header file itself.

So we eventually decided to get the user a clear message, and place
the burden onto the library programmer to write up two
"implementations" of his macros: one simplified, just for
documentation (#ifdef'ed in __DOXYGEN__), and another one that forms
the actual implementation.

This is basically a problem with macro #defines only. All other items
don't get their implementation details added by doxygen anyway.

As doxygen has a tendency to document everything and all it can find
in the sources, this also allows to exclude certain internals (usually
stuff starting with two underscores) from doxygen's considerations
completely.

>> In particular the deprecation of ISR_ALIAS() in favour of
>> the ISR_ALIASOF() attribute to ISR() is something that won't be merged
>> back into the stable (1.4.x) branch.

> I've never understood how that works. Does that mean that the
> ISR_ALIASOF() attribute will be thrown out eventually?

No, you've got that the wrong direction: I marked the old ISR_ALIAS()
macro "deprecated" in the new version (that's the macro you've been
calling ISR_ALIAS_COMPAT()), in favour of your new ISR_ALIASOF()
attribute. So, ISR_ALIAS() is still there in 1.5.1 (and will also be
in 1.6.x), but it might be moved out into in a
future release (but not before 1.8.0).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

> Just in case anyone starts writing 64-bit float. I think this
> bug
> should be solved first.

Ah well. If we only knew someone who could really fix it.

The point here is, the actual bug is in GCC's middleend code (rather
than in the AVR backend), but this bug apparently doesn't manifest
itself on other targets as all the important targets (at least those)
do provide machine-dependent code to push arguments onto the stack.
So there's apparently noone able *and* interested in fixing this.

OTOH, the AVR backend could go the same route, and provide a
machine-specific implementation to push the args onto the stack, but
again, it takes someone who understands enough of GCC to do... I've
already discussed that with Björn, but he didn't have at least a quick
idea. This means, it can probably take quite a bit of time (and
knowledge) to do this.

> And I personally think implementing something like Bjoern Haasse has
> proposed
> here
> is a much greater win.

Greater than what? A 64-bit FP implementation? I don't see them as
related in any way. Given the number of people who are now starting
to perform GPS calculations on large AVRs, I think *any* 64-bit FP
implementation will be a win to them, even if it is slow and bloated,
provided it is at least accurate. You obviously wouldn't want to run
that on an ATTinyXX (or ATmega48) anyway.

But of course, I agree that incorporating Björn's approach would be a
Good Thing. Maybe you could convince Anatoly of that? He's got AVR
commit privileges to the GCC tree.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

dl8dtl wrote:
Ah well. If we only knew someone who could really fix it.
That's why I called it to attention. If no one is going to fix this, then you really need to be carefull parsing arguments. Potentially making the 64-bit FP hard to work with.
dl8dtl wrote:
Greater than what?

I could not see a reason why one would need 64-bit FP calculations. So I thought it was a matter of getting closer to the standard, rather then improving current gcc. So it was in the sense of "smaller code" vs "being compliant to the standard by adding pratically unused functionality"
But if there actually is need for 64bit FP then it's equal to me.

I also thought it might be a easier to get to know gcc by implementing this patch as a start and then start to create something new, instead of immediatly start writing from scratch.

Quote:

But of course, I agree that incorporating Björn's approach would be a
Good Thing. Maybe you could convince Anatoly of that? He's got AVR
commit privileges to the GCC tree.

I will try to see if I can strip the patch and send it to Anatoly.

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

@Dean
Sorry, but I think I've only looked at the tutorial about making some sort of sandwich. Seemed like a reasonably good one to me. ;) I apologize. I just haven't had the time to go look through there. But I've heard nothing but good things about the tutorials there, and I'd like to see them get into the documentation.

@Cliff
Joerg gave you the run-down on what is needed for 64-bit double support. I wouldn't worry about the GCC side of things at the moment, as you probably need to be somewhat familiar with the AVR target in GCC. Perhaps one of us (me, Joerg, or Anatoly) can help on that side. What is really needed is for someone to write the standard C library math functions (for inclusion with avr-libc) and come up with a reasonable ABI for that. What's nice about this feature is that it is not critical to have it at the moment, so you can take your time, but it would major kudos to the person who did it. Besides the reason that this feature would be good for the GPS users, it is also a marketing point: IAR has the capability to do 64-bit FP. It would be nice if AVR GCC could too. ;)

@Wouter
I agree that that bug should be fixed. Along with some other ones too. I have a list. ;) Any help is very much appreciated! I certainly appreciated your analysis on GCC bug #31644. BTW, could you post your analysis to that bug report? I know you sent it to the avr-libc-dev list, but it would be great if it was recorded in the bug report also. You can certainly send something to Anatoly, but I don't know how much time he has. I know that he's been working on all sorts of other patches too.

Eric

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

Eric,

So am I being too simplistic in thinking that it's just a case of taking 32 bit routines like fdivmul3 (or whatever it's called) and expanding it out to work on wider mantissa's (effectively) ?

Cliff

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

JohanEkdahl wrote:
And us oldies should be very proud of Dean - we taught him almost everything he knows...
That's why you have so little left! :lol: :wink:

I intend to help with gcc/avr-libc after I take time to compile my m2560 changes to FreeRTOS and submit those. Of course, we all know which road is paved with good intentions...

Stu

PS: Comeback ripped off from Victor/Victoria

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

clawson wrote:
Eric,

So am I being too simplistic in thinking that it's just a case of taking 32 bit routines like fdivmul3 (or whatever it's called) and expanding it out to work on wider mantissa's (effectively) ?

Honestly, I don't know the issues involved. Maybe. Maybe not. I have never looked into myself.

Note that the fdivmul3 routine (and its ilk) is in libgcc IIRC.

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

clawson wrote:
So am I being too simplistic in thinking that it's just a case of taking 32 bit routines like fdivmul3 (or whatever it's called) and expanding it out to work on wider mantissa's (effectively) ?
The exponent has a wider range also,
but massaging things like fdivmul3 would likely work for arithmetic.
It would still necessary to do the math to
ensure that the error was less than an ulp.

Different formulas would have to be used for the trig functions.

What accuracies over what ranges do we want for the trig functions?

Do fdivmul3 and its relatives use the standard function interface?
In principle, since it's used internally,
register usage could be part of the interface.
The compiler could use that knowledge.

Iluvatar is the better part of Valar.

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

Why would different functions be needed for trig? Surely they are just calculated using Taylor Series or something and fundamentally boil down to the simple arithmetic +, -, *, / ? So if one implements 64 bit versions of those one would be well on the way to implementing it all?

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

> Why would different functions be needed for trig?

Most of the functions are currently hand-optmized assembly
source code.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

clawson wrote:
Why would different functions be needed for trig? Surely they are just calculated using Taylor Series or something and fundamentally boil down to the simple arithmetic +, -, *, / ? So if one implements 64 bit versions of those one would be well on the way to implementing it all?
The Standard C Libraryby P. J. Plauger deals with exactly this.
The best approximations are not Taylor series or even polynomial.
My recollection is that his were rational functions.
He used some interesting tricks to do mod 2pi accurately for large arguments.
Since he had hardware double precision and we don't,
we would want to do things a little differently.

Iluvatar is the better part of Valar.