WinAVR continuation

Last post
86 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I've decided.

I'm going to continue WinAVR.

I would like to come out with a release say in the next 3 months (or less, if I can swing it).

It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.

Joerg has mentioned a new avrdude and avarice release as well, but realize that his time is spread thin across multiple projects.

We have to work out what version of avr-gcc to include and what kinds of patches it needs to contain. There's a number of bug fixes that need to be done.

I'm sure there will updates on other tools as well.

Bug reports, patches, and constructive feedback welcome. And help on any of the projects is always welcome too.

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

Hi EW,

Awesome news!! Thanks for your hard work!

Alan

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

Does this mean then that this will just work with Studio 4.xx?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

It works the other way around. The IDE has to be built such that it works with any installed toolchain. I'm not in control of the IDE portion.

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

If you need any help (with documentation, what ever), please shout, scream, or otherwise pull my chain. Not much experience, but It is something I ought to be able to help with.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

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

Good news, Eric!

"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]

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

Looking forward to it.

Jan

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

Great news. "Toolchain" was starting to look a lot like a half baked lame duck.

 

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

EW wrote:
I'm going to continue WinAVR.

Hi Eric, that's very good news! What base version?

Quote:
I would like to come out with a release say in the next 3 months (or less, if I can swing it).

Is there any effort on your side to fix the evil PR46779/45291/41894 issue? I did not yet backport and 4.7 changes.

Quote:
It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.

What is the rationale behind poisoning the SIG_ semantic sugar?

That will render many applications to freak without any need, that just builds up barriers. There have been two nomanclatures in avr-libc:

Numenclatur of avr-libc with SIG_ prefix.

Names that occured in any target manual, suffixed _vect. If a vect is renamed in the handbook because of some update, new versions of avr-libc should NOT remove the old name but still support it. For example some handlers are named TIM0_* and others TIMER0_*.

If some name ever existed, it should persist to do so.

There are already enough barriers useres have to cope with, so I do not understand yet another, pure artificial barrier.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
EW wrote:
I'm going to continue WinAVR.

Hi Eric, that's very good news! What base version?

Good question. I don't have an immediate answer on that. This is one of the main things that we need to look into in order to do the release. I know that there are issues in GCC 4.5.x, 4.6.x, and trunk (future 4.7). We need to figure out which version and which set of patches to include. Very likely some bugs need to be fixed before a release.

SprinterSB wrote:

Quote:
I would like to come out with a release say in the next 3 months (or less, if I can swing it).

Is there any effort on your side to fix the evil PR46779/45291/41894 issue? I did not yet backport and 4.7 changes.

Certainly we need to go through the bug list and address issues like those. There has been work done recently by Georg-Johann Lay on various bug reports, which has been very much appreciated.

SprinterSB wrote:

Quote:
It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.

What is the rationale behind poisoning the SIG_ semantic sugar?

That will render many applications to freak without any need, that just builds up barriers.

Technically, the SIG_* names have been deprecated for years. The *_vect names have been preferred. We've been slowly moving to those names over time, mainly because they are compatible with IAR. If you have noticed, new device support does NOT contain the old SIG_* ISR naming.

What we have not had in avr-libc in the past, is an easy way to tell the user what is deprecated and what is not. With the upcoming 1.8.0, these old deprecated names are now "poisoned" so that if they are used in an application the compiler will generate an error. However, the good thing with our deprecation system is that any user can easily get to the deprecated names just by defining an identifier before including io.h and then all of the deprecations are immediately available without warnings or errors.

The point of deprecations is that they eventually will go away. We try to give ample warnings to the end user so they have time to change their applications to any new system. Please realize that we are actually very conscientious about keeping old names around for a long time. We are keenly aware about backwards compatibility. But in the end, those SIG_* names are outdated, and they are not used across all devices. The *_vect names are used across all devices.

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

EW wrote:
There has been work done recently by Georg-Johann Lay on various bug reports,
[whisper] SprinterSB IS Georg-Johann Lay ;-) [/whisper]

Stefan Ernst

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

sternst wrote:
EW wrote:
There has been work done recently by Georg-Johann Lay on various bug reports,
[whisper] SprinterSB IS Georg-Johann Lay ;-) [/whisper]

See? Even I can't keep track of all the people and their handles! :roll:

Well then let me just add that I'm also going to see what can be done internally to get these bugs fixed.

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

EW wrote:
SprinterSB wrote:
What base version?
Good question. I don't have an immediate answer on that. This is one of the main things that we need to look into in order to do the release. I know that there are issues in GCC 4.5.x, 4.6.x, and trunk (future 4.7). We need to figure out which version and which set of patches to include. Very likely some bugs need to be fixed before a release.
Besides that, the ABI needs to be updated
  • The ABI should state what the compiler can/will handle concerned SFRs like RAMP* and EIND. If the user has to fiddle with that, the ABI should say that. Ditto if or if not pro/epilogue saves them or not. It should be stated if these regs might be undefined in main or startup should restore reset value (PR44940).
  • ABI has to be adaped to actual avr-gcc behaviour for return type promotion as discussed recently and which is de-facto ABI since 4.3.
  • ABI should mention T-flag: It's used similar to the fixed __tmp_reg__ by avr-gcc.

avrfreaks does not support Opera. Profile inactive.

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

> ABI should mention T-flag: It's used similar to the fixed __tmp_reg__ by avr-gcc.

Curious: where is it being used?

I remember the old FP library using it, but that should be gone now.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

Quote:

Curious: where is it being used?

I thought I'd read it was used inside printf()? Maybe that info is "out of date" these days? (or maybe I remembered wrong?)

 

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

Yeah, the priority is always
- Fix wrong code bugs first
- Optimization bugs later.

SprinterSB wrote:

If it's wrong code, it should be fixed.

SprinterSB wrote:
  • PR48459: breaks DWARF in 4.6 and 4.7. Maybe Eric B. can have a look?

I've let our internal team know about this. But it needs to be made a priority.

SprinterSB wrote:

Code bloat is still lower priority (compared to wrong code).

SprinterSB wrote:
  • PR45263: Minor issue, easy to port

If it's low-hanging fruit, then we should see about getting it done.

SprinterSB wrote:
  • PR34734: Annoying. In C, DECL_INITIAL is available, but in C++ it is empty even if there is an initializer. (presumably because of different FE). Maybe avr-libc could take care of that by conditionally definig PROGMEM as section attribute for C++?

Yeah, overall I would like to see more of the C++ issues get fixed. If it's easier to do the fix in avr-libc, then let's get it done.

SprinterSB wrote:
    Besides that, the ABI needs to be updated
    • The ABI should state what the compiler can/will handle concerned SFRs like RAMP* and EIND. If the user has to fiddle with that, the ABI should say that. Ditto if or if not pro/epilogue saves them or not. It should be stated if these regs might be undefined in main or startup should restore reset value (PR44940).
    • ABI has to be adaped to actual avr-gcc behaviour for return type promotion as discussed recently and which is de-facto ABI since 4.3.
    • ABI should mention T-flag: It's used similar to the fixed __tmp_reg__ by avr-gcc.

ABI changes are much bigger and long-term. I don't think that this should be done for a WinAVR release but we need to make sure all the developers are on the same page for any changes.

...And sorry for not knowing your username here on Freaks. *cough* :oops:

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

dl8dtl wrote:
> ABI should mention T-flag: It's used similar to the fixed __tmp_reg__ by avr-gcc.

Curious: where is it being used?


abs(float), -float, to setup shift counter, &~(1<<const), |(1<<const), =(1<< const), ... with high register pressure i.e. stuff that ends up in l-regs.

Just look for bld in
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.c?view=markup
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.md?view=markup

avrfreaks does not support Opera. Profile inactive.

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

> Just look for bld in
> http://gcc.gnu.org/viewcvs/trunk/gcc/co ... iew=markup
> http://gcc.gnu.org/viewcvs/trunk/gcc/co ... iew=markup

Hmm. Things nobody ever told us about we could not document in
the avr-libc documentation ...

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

TFrancuz wrote:
And please, remember about Bug c++/43745 – it is really annoying to have vtables in SRAM:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745

I haven't forgotten, however technically that is an enhancement. It's going to have lower priority than a wrong-code bug.

The goal is to get this out in 3 months or less. We have limited resources, so we have to prioritize the issues. The more help there is, the more we can address.

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

I haven't played around in the GCC internals sandbox yet but I'd be happy to help in any way possible.

Martin Jay McKee

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

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

Brilliant Eric! Glad to hear it, as I'm sure the Arduino folks will be too (they pull from WinAVR for their Windows environment, correct?). The Atmel toolchain works fine for me, but is missing mfile and the GNU tools associated with it that I and many others rely on for making external makefiles outside of Studio.

- Dean :twisted:

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

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

Quote:
I'm sure the Arduino folks will be too
Don't know about that. Their latest version 0022 still uses WinAVR-20081205!!

...don't ask how I know, too painfull to recall...but it's a job.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Their latest version 0022 still uses WinAVR-20081205!!

...don't ask how I know, too painfull to recall...but it's a job.

Please, tell (not about your pain, only the raw reason ;-) ).

Just let me guess first. They overwrite the PATH without warning. But isn't it the way how WinAVR's installer works, too? This IMHO deserves a bit of thought...

(...add my usual b***ing about lack of changelog ... and other documentation... like why can't there be a toolchain documentation, and why is avr-libc's documentation seen as substitute... now comes Joerg saying "oh yeah and what of that is YOU going to do... I shut up now...)

Jan

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

Don't want to derail the thread with Arduino stuff now. :-) But it seems a perfect environment for brain dead people who don't want to know anything about the hardware or the software and just make lights blink.

Should we start another thread for the firefight? :mrgreen:
[yes + 1 :-)]

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Don't want to derail the thread with Arduino stuff now. :-) But it seems a perfect environment for brain dead people who don't want to know anything about the hardware or the software and just make lights blink.

Should we start another thread for the firefight? :mrgreen:


To discuss what?

The technical merits and shortcomings of Arduino/environment, or the mental shortcomings of their proponents and users? :-)

I'd love to hear more on the former from a professional's viewpoint. I don't Arduino and I don't dig the idea, but I love to hear about others' failures... ;-)

Jan

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

Quote:

Just let me guess first. They overwrite the PATH without warning. But isn't it the way how WinAVR's installer works, too?

Wrong I'm afraid. Arduino happily co-exists with other WinAVRs - it does not touch the PATH. I guess it knows where it's installed and just invokes its own local WinAVR utilities absolutely.

 

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

clawson wrote:
Quote:

Just let me guess first. They overwrite the PATH without warning. But isn't it the way how WinAVR's installer works, too?

Wrong I'm afraid. Arduino happily co-exists with other WinAVRs - it does not touch the PATH. I guess it knows where it's installed and just invokes its own local WinAVR utilities absolutely.
Okay, I lost, I pay. Which bar today, Cliff? ;-)

Jan

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

WINAVR wish list:

Is it possible to add a method to define structs inside the Flash?

E.g.:

typedef struct{
  char __ATTR_PROGMEM__ *name;
  uint8_t (__ATTR_PROGMEM__ *func)();
}comm_struct;


comm_struct __ATTR_PROGMEM__ comm_tab[] = {     // command table
        "REM", remote,
        "LOC", local,
        "STAT", status,
        "", NULL                                // end of table
};

Peter

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

Eric,

Actually Peter's request makes me wonder where GCC is with generic multi-memory space support?

Cliff

 

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

> where GCC is with generic multi-memory space support?

Ask Georg-Johann.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

dl8dtl wrote:
> where GCC is with generic multi-memory space support?

Ask Georg-Johann.

Actually, last I heard is that it was being worked on internally. I'll be finding out the status of various work on the toolchain in about 2-3 weeks.

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

As to the Arudino topic:

I understand that there are engineers that work in the embedded field that don't think highly of the Arduino environment, and I can understand their reasoning.

However, the Arduino boards and programming environment has done more to get people involved in doing something with embedded systems than anything else, and ultimately it should not be disparaged. Everyone at some point had to go along the engineering learning curve with embedded systems. The Arduino environment represents just part of that spectrum. It gets people excited about doing something with embedded systems, and that's a good thing, not a bad thing.

So if you don't like it, then go change the channel and ignore the talk about it.

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

mckeemj wrote:
documentation might come a near second, however, where there are specific requests for clarification ( I've personally found the avr-libc documentation sufficient ).
Do you mean the documentation documents sufficiently avr-libc's functionality; or you mean that the status-quo of avr-libc documentation documenting the whole toolchain is adequate?

I beg to disagree with the latter.

Jan

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

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

EW wrote:
Quote:
[named address spaces]
Actually, last I heard is that it was being worked on internally. I'll be finding out the status of various work on the toolchain in about 2-3 weeks.

Is there a development branch in the repository? Would make sense that. For collaboration.

danni wrote:
Is it possible to add a method to define structs inside the Flash?
That's already possible today by means of PROGMEM or section attribute.

The only thing that does not work as intended in your example is placement of string literals. But even with named address spaces I do not know if it is possible in a consistent way to treat a literal like the following example:

const char __pgm * p = "A"

It's clear what the intention is, but "A" will be in RAM and p point to a flash location. There is no way like suffix to say where "A" should be placed; so it is always in the generic address space aka. RAM. This is in contrast to

const char __pgm q[] = "B"

where "B" will end up in flash.

Then note that the address space support is done for C and limited to intrinsic address spaces, I see nothing that does an extention for C++ except the note

DTR 18037 wrote:
Named address space support could be added to C++ only as an extension; it would not be implementable within the class library. Such an extension would not conflict with existing features of C++.

A solution to put "A" (or in more complex cases like struct initializer) in flash would be pragma, so that code could look something like

#pragma avr progmem
const struct foo = 
{
    "C", bar
};
#pragma avr

Pragma support would not be restricted to C and is easier to implement than intrinsic named address spaces. GCC only supports intrinsic named address spaces at the moment; afaik there is no work in progress to support other flavours of named addresses.

mckeemj wrote:
At the moment it is functional, but it does have distinct ( and visible ) drawbacks. Perhaps the programmers that run into the issues should choose another approach, but it is never good to see things that you know could be "right" but aren't. A place I see the same issue in the avr-libc support is ( at least last I checked ) 64-bit arithmetic. People who attempt to use it are likely to get a large ( in many ways ), and quite unpleasant surprise.

Anyone who works or did work on avr-gcc is well aware of that. If the code is not as good as could be, that has basically two reasons:
  • If just a tenth of the effort that is put into, e.g. arm-gcc, would be put into avr-gcc, avr-gcc would be much better off.
  • GCC is a complex software and teaching it things is [i]hard[/]. Gernerally, when looking at code produced by the compiler it is easy to put the finger on a particular spot and say: "what a dumb compiler, I see immediately how good code would look like, why isn't the compiler producing it?".

    It's two completely different things to see that the code is not optimal and to actually fix that in a consistent, maintainable, efficient, generic way.

So if something is not implemented, like more efficient 64-bit support, it's because that is beyond resources. Comments like "it's no problem, just replace LDS by LPM" are in crass discrepancy to an actual implementation.

mckeemj wrote:
I haven't played around in the GCC internals sandbox yet but I'd be happy to help in any way possible.
Half the way is doing a fix/extension, another half is pure bureaucracy (GPL, coding convention, SVN, ...) and yet another half is to convince a maintainer to approve the work.

So you could start with the annoying second point, because without some formalities the work might be unused and thus frustrating.

From the technical aspect, starting points are reading the internals and tying to get the big picture how GCC works and how a backend hooks in in order to accomplish its needs.

Learn how to build GCC so that it incorporated you changes and learn about ways to debug GCC and how testsuite is run.

Pick an issue, e.g. from bugzilla, that appears to be easy to fix and try to understand what's going wrong, how it can be improved and why the improvement is correct for any other input source code that is imagineable.

EW wrote:
ABI changes are much bigger and long-term. I don't think that this should be done for a WinAVR release [...]
ACK for the last point. ABI change is independant of release cycle.

But note that avr-gcc uses/changes some resources; there is the example of T-flag. Without saying a word about that users could stumble because without any documentation one might conclude that the thing is unchanged.

Similar for RAMPZ: you would expect that at beginning of main it has it's reset value or the value you assigned in some constructor or .init-function, but actually it is undefined because startup code might clobber it.

So even if it's not labeled "ABI change/extention", it should be documented. A place could be avr-libc which takes the burdon of documenting many stuff that is actually beyond avr-libc.

Without being clear about such things, on the one hand, users are confused or mislead or produce buggy code without having the chance to know that beforehand, and on the other hand tool developers have no idea how a bug report like PR44940 has to be treated: is the report invalid? or is there a bug? what part of the chain is reposible for the bug?

Doing nothing about that is not the best option, imo.

avrfreaks does not support Opera. Profile inactive.

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

Wish list part 2:

- 64 bit support not so enormous ressource gulping.
- double float support

Peter

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

Hi,

danni wrote:
Wish list part 2:
- 64 bit support not so enormous ressource gulping.
- double float support
Peter

I agree, both of these would be awesome.

Here is the 64 bit div: 3306 bytes!
00000696 00003306 T __udivdi3

Thanks,

Alan

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

If there aren't enough volunteers to even fix the bugs who do people think will be implementing these "wishlist" items that could actually represent many man months of (free) development time? Even if there were engineering resource available surely there'd need to be some kind of prioritisation? In reality how many people using AVRs really need (not just want!) to use things like uint64_t or double?

 

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

A few comments:

@wek - yes, my documentation comment was directed at avr-libc functionality, not the tool chain. However, much of the tool chain, in my experience, is documented ( sparsely and somewhat cryptically perhaps ) "somewhere"; it simply is not written up cleanly and in a central location. But... and I think this is the biggest issue, the tool chain represents an amalgam of projects and thus almost demands this separate documentation. Does it make sense to create an entire AVR specific binutils manual ( or similar )? I think that is asking a bit much.

@SprinterSB - I've already started looking over the internals manual and I've joined the avr-libc-dev list, so hopefully I'll be able to get up to speed in the next couple of weeks to do something useful.

As for my reference to 64-bit arithmetic... I do not want to imply that avr-libc needs an improved implementation - the current implementation works. I also cannot argue that those who have worked with avr-libc for a time will recognize the issues involved with it 64-bit numbers and avoid them unless absolutely required. What I have seen, here on AVRFreaks, however, is people coming to this with little or no experience and then running away just as quickly when they find out how "bloated" their code is with certain features ( including 64-bit arithmetic ). This is similar to the let down that, currently, doubles are the same size as floats. The float / double, situation, however is documented; except for possibly ( I have not checked ) bugzilla, the 64-bit unoptimized status is not ( documented that is ).

Granted, we cannot expect many people to "rush to the documentation" ( either before or after trouble strikes ). But an acknowledgment of "this is the current state of this piece, take it or leave it ( or even, here's why )", goes a long way toward making the software seem more stable and usable. This does not belong in the functional documentation, of course, as any potential future improvements in the underlying code should not change the functionality, but something in the form of a development road map or project status diagram ( beta, stable - unoptimized, stable - optimized, etc. ) would condense the information into an easily usable ( and maintainable ) form.

Martin Jay McKee

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

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

Note that at Jan's request I have split the intricate discussion about improving uint64_t support from this thread and into a separate one.

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107472

(BTW I could do the same for the vtables "tangent" too ;-))

Cliff

 

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

Quote:
I could do the same for the vtables "tangent" too

thread.SplitVotes(Posts.Tangent.VTABLES))++;

EDIT: Minor typo. Also Explanation, for the ignorant (i.e. Cliff :wink:); The object thread is of a class that has a method (member function) to access/modify an attribute/property/whatever of that object that keeps track of votes to break out posts with a given "tangent". Possible tangents are enumerated in The Posts class, in the Tangent enum. In this instance the VTABLES tangent is used.

"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]

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

But Johan you know I'm not going to understand that alien syntax ;-)

 

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

Split so that all those masses that use 64-bit variables on AVRs can have easier access. I'm sure those great masses that need the vtable mess (or even comprehend why it is a mess) would like that in another thread also.

And thank you Cliff. I was getting ready to throw in the towel and take up model trains as a hobby.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

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

OK I've done it (or tried!). The "vtables" discussion is now in this thread:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107490

(if anyone spots posts that should have been moved but haven't been or those that shouldn't have but have then let me know and I can move things about)

NB I made the split because they are both (uint64_t / vtables) interesting discussion for future developments in avr-gcc but they have no relevance to a WinAVr release in ~3 months.

 

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

Quote:

Yeah, the priority is always
- Fix wrong code bugs first

ATtiny4 is not supported in WinAVR(Last release) but supported by AVR-8bit tool Chain.

REASON?

ATMEL--Heart Beat
Nothing Impossible

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

Quote:

ATtiny4 is not supported in WinAVR(Last release) but supported by AVR-8bit tool Chain.

REASON?


it's obvious isn't it? The current "latest" WinAVR dates from 20100110. That is now 17 months ago. That's the whole point of Eric looking to do a new one to catch things like new device support. Sure later gcc, binutils and AVR-LibC have made it into the later "toolchain" but that's a total dog's breakfast.

 

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

As question on LTO (link time optimization) got kicked out of this thread to http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=831470#831470
...and I am still curious if the release will be built with LTO enabled, let me bring this question back again:

SprinterSB wrote:
The only low-hanging optimization fruit that is available ouside current development branch is LTO. I don't know if Eric plans to build the release with LTO enabled and what version of binutils he prefers.

avrfreaks does not support Opera. Profile inactive.

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

It would be nice, if the new WINAVR would include this routines for better 64bit support:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113673

Then no longer at least a 16kB AVR was needed for 64bit (about 8kB only for mul/div alone).
Then mul/div need only 208 byte instead. :!:

Peter

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

danni wrote:
It would be nice, if the new WINAVR would include this routines for better 64bit support:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113673

Just skimmed the routines. They use R4...R7 which is not approppriate for an official release because these registers might be fixed, i.e. it's legal for an application to do -ffixed-4 etc.

avrfreaks does not support Opera. Profile inactive.

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

Here is a drop-in replacement for libgcc for 64-bit multiplication:

/*******************************************************
       Multiplication 64 * 64
*******************************************************/

#if defined (L_muldi3)

;; A[] = A[] * B[]

;; A[0..7]: In: Multiplicand
;; Out: Product
#define A0  18
#define A1  A0+1
#define A2  A0+2
#define A3  A0+3
#define A4  A0+4
#define A5  A0+5
#define A6  A0+6
#define A7  A0+7

;; B[0..7]: In: Multiplier
#define B0  10
#define B1  B0+1
#define B2  B0+2
#define B3  B0+3
#define B4  B0+4
#define B5  B0+5
#define B6  B0+6
#define B7  B0+7

#if defined (__AVR_HAVE_MUL__)

;; Define C[] for convenience
;; Notice that parts of C[] overlap A[] respective B[]
#define C0  16
#define C1  C0+1
#define C2  20
#define C3  C2+1
#define C4  28
#define C5  C4+1
#define C6  C4+2
#define C7  C4+3

DEFUN __muldi3

    push    r29
    push    r28
    push    r17
    push    r16

    ;; Counting in Words, we have to perform a 4 * 4 Multiplication

    ;; 3 * 0  +  0 * 3
    mul  A7,B0  $             $  mov C7,r0
    mul  A0,B7  $             $  add C7,r0
    mul  A6,B1  $             $  add C7,r0
    mul  A6,B0  $  mov C6,r0  $  add C7,r1
    mul  B6,A1  $             $  add C7,r0
    mul  B6,A0  $  add C6,r0  $  adc C7,r1

    ;; 1 * 2
    mul  A2,B4  $  add C6,r0  $  adc C7,r1
    mul  A3,B4  $             $  add C7,r0
    mul  A2,B5  $             $  add C7,r0

    push    A5
    push    A4
    push    B1
    push    B0
    push    A3
    push    A2
    
    ;; 0 * 0
    wmov    26, B0
    XCALL   __umulhisi3  $  wmov C0,22  $  wmov C2,24

    ;; 0 * 2
    wmov    26, B4
    XCALL   __umulhisi3  $  wmov C4,22  $  add  C6,24  $  adc C7,25
    
    wmov    26, B2
    ;; 0 * 1
    rcall   __muldi3_6

    pop     A0
    pop     A1
    ;; 1 * 1
    wmov    26, B2
    XCALL   __umulhisi3  $  add C4,22 $ adc C5,23 $ adc C6,24 $ adc C7,25

    pop     r26
    pop     r27
    ;; 1 * 0
    rcall   __muldi3_6
    
    pop     A0
    pop     A1
    ;; 2 * 0
    XCALL   __umulhisi3  $  add C4,22 $ adc C5,23 $ adc C6,24 $ adc C7,25

    ;; 2 * 1
    wmov    26, B2
    XCALL   __umulhisi3  $            $           $ add C6,22 $ adc C7,23
    
    ;; A[] = C[]
    wmov    A0, C0
    ;; A2 = C2 already
    wmov    A4, C4
    wmov    A6, C6

    clr     __zero_reg__
    pop     r16
    pop     r17
    pop     r28
    pop     r29
    ret
    
__muldi3_6:    
    XCALL   __umulhisi3
    clr     __zero_reg__
    add     C2, 22
    adc     C3, 23
    adc     C4, 24
    adc     C5, 25
    adc     C6, __zero_reg__
    adc     C7, __zero_reg__
    ret
    
ENDF __muldi3

#undef C7
#undef C6
#undef C5
#undef C4
#undef C3
#undef C2
#undef C1
#undef C0

#else /* !HAVE_MUL */

#define C0  26
#define C1  C0+1
#define C2  C0+2
#define C3  C0+3
#define C4  C0+4
#define C5  C0+5
#define C6  0
#define C7  C6+1

#define Loop 9

DEFUN __muldi3

    push    r29
    push    r28
    push    Loop

    ldi     C0, 64
    mov     Loop, C0

    ;; C[] = 0
    clr     __tmp_reg__
    wmov    C0, 0
    wmov    C2, 0
    wmov    C4, 0
    
0:  ;; Set T = N-th Bit of B[] where N = 64 - Loop...
    bst     B0, 0
    
    ;; ... and rotate B[] right by 1
    ;; Notice that B[] = B[] >>> 64 so after this routine has finished,
    ;; B[] will have its initial Value again.

    LSR  B7     $  ror  B6     $  ror  B5     $  ror  B4
    ror  B3     $  ror  B2     $  ror  B1     $  ror  B0
    bld     B7, 7
    
    ;; If the N-th Bit of B[] was set...
    brtc    1f
    
    ;; ...then add A[] * 2^N to the Result C[]
    ADD  C0,A0  $  adc  C1,A1  $  adc  C2,A2  $  adc  C3,A3
    adc  C4,A4  $  adc  C5,A5  $  adc  C6,A6  $  adc  C7,A7
    
1:  ;; Multiply A[] by 2
    LSL  A0     $  rol  A1     $  rol  A2     $  rol  A3
    rol  A4     $  rol  A5     $  rol  A6     $  rol  A7
    
    dec     Loop
    brne    0b
    
    ;; We expanded the Result in C[]
    ;; Copy it to the return Register A[]
    wmov    A0, C0
    wmov    A2, C2
    wmov    A4, C4
    wmov    A6, C6

    clr     __zero_reg__
    pop     Loop
    pop     r28
    pop     r29
    ret
    
ENDF __muldi3

#undef Loop

#undef C7
#undef C6
#undef C5
#undef C4
#undef C3
#undef C2
#undef C1
#undef C0

#endif /* HAVE_MUL */

#undef B7
#undef B6
#undef B5
#undef B4
#undef B3
#undef B2
#undef B1
#undef B0

#undef A7
#undef A6
#undef A5
#undef A4
#undef A3
#undef A2
#undef A1
#undef A0

#endif /* L_muldi3 */

In order to use it in a private, stand-alone project, do the following:

  • Copy-paste needed definitions like DEFUN, ENDF, XCALL, wmov from libgcc or write your own replacement macros.
  • If you want to use the MUL-version you need a function __umulhisi3 that can perform
    R25:22 = (unsigned long) R27:26 * R19:18

    .

  • Add the following lines before the code:
    #define L_muldi3
    .text

  • Add ia as assembler file to your project.
Compiled with some avr-gcc 4.7 snapshot for ATmega168 this routines return the following
   __muldi3     | Size  |    Ticks
----------------+-------+-------------
vanilla libgcc  |  400  |          860
asm with MUL    |  176  |          350
asm without MUL |   94  |  1500...2000

Notice that only the "without MUL" version is stand-alone, the other flavours need functions like the mentioned __umulhisi3.

For signed/unsigned quotient and remainder, there is already a 64-bit implementation in 4.7 that even trades size against speed. All you have to do in order to use it in versions < 4.7 is to backport this patch.

avrfreaks does not support Opera. Profile inactive.

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

Hi,

could we please have an update about when the release is going to happen?

Pages