GCC 4.5 "named address space" feature and AVR

Log in or register to post comments
Go To Last Post
24 posts / 0 new
Author
Message
mojojojo
mojojojo's picture
Level: Hangaround
Joined: Sun. Aug 14, 2005
Posts: 212 View posts
Location: Ecotopia
#1
Posted by mojojojo: Tue. Jan 12, 2010 - 11:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I happened to notice that GCC 4.5 implements a new feature called "named address spaces", which seems to have come from ISO as a feature needed for various embedded processors. The initial implementation is for the SPU on Cell processors.

So my question: is AVR-GCC growing support for that?

It seems to me that "progmem" is a natural fit for this feature, and should be able to simplify one of the more annoying bits of AVR-GCC programming: accessing data stored in flash. Handling I/O addresses this way is less obviously advantageous; that's not so annoying today, but more standardized I/O access might help avoid some bugs.

Clearly, avr-libc support for that stuff would be a separate set of issues, with considerations like portability and backwards compatibility.

But it'd all need to be built on top of GCC support, which won't be in the 4.5 release. So ... maybe in GCC 4.6?

Tags:

Tools, Compilers and General Programming
Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4934 View posts
Location: Rocky Mountains
Posted by EW: Wed. Jan 13, 2010 - 12:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojojojo wrote:
I happened to notice that GCC 4.5 implements a new feature called "named address spaces", which seems to have come from ISO as a feature needed for various embedded processors. The initial implementation is for the SPU on Cell processors.

So my question: is AVR-GCC growing support for that?

Yes. Next question.

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
mojojojo
mojojojo's picture
Level: Hangaround
Joined: Sun. Aug 14, 2005
Posts: 212 View posts
Location: Ecotopia
Posted by mojojojo: Wed. Jan 13, 2010 - 03:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Yes. Next question.

Thanks; that's a good answer ("yes") albeit partial ... my post had two question marks already, you must have skipped the second one. ;)

The second question was "when" -- in GCC 4.6?

The best answer would be "well before that, via patches folk can add to 4.5 to work with in order to get the feel of this." That would help smooth all the follow-on work. There'd be something of a community learning curve to address, and such things benefit from having some time. I'm in no personal rush here, but I'm sure that when such patches start to circulate I'd allocate time to use them with an AVR project.

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4934 View posts
Location: Rocky Mountains
Posted by EW: Wed. Jan 13, 2010 - 04:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojojojo wrote:
The second question was "when" -- in GCC 4.6?

Hard to say exactly. The generic parts of the named address space feature has been committed to mainline, which is HEAD, which is also future 4.5. Now this feature still needs to be ported to the AVR port. I don't know if it will be done in time for the general 4.5 release, but conceivably it could be done as an add-on patch to some 4.5.x release. A lot depends on how the work goes and available resources.

*Ideally* I would like to see it in a 4.5.x release. But I'm not going to promise you vaporware. Best thing to do is to check back in a few months to see how progress is going. Feel free to email me about it, if you prefer. But I can tell you right now that it probably won't even be close to ready in the next 2 months.

Hope that helps.

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Wed. Jan 13, 2010 - 08:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Approximately a half year ago, we have discussed this issue:

EW in https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=600427#600427 wrote:
wek wrote:

Well, assuming the yearly pace of gcc minor releases, and then a year to get things settled for avr-gcc, we are talking about two, maybe three years, plusminus. Correct?

Unfortunately, yes. I hope that we could actually move the date closer, perhaps cut that time in half. I would prefer a year to maybe a year and a half. But a lot of things have to go well for this to happen in that time frame.

Top
TFrancuz
TFrancuz's picture
Level: Resident
Joined: Fri. Jan 10, 2003
Posts: 575 View posts
Posted by TFrancuz: Wed. Jan 13, 2010 - 09:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eric, because as always you are well informed, may I ask you about C++ and VTABLES. Do you know if somebody works on moving it to FLASH? Now they are copied into SRAM which is extremely annoying, and wastes a lot of precious SRAM. Can we expect a patch for gcc 4.4 or possibly 4.5? I tried to do that, but it is very hard to begin with gcc sources, another problem is the lack of information about internal gcc structure and how things are done.
TIA.

Top
mojojojo
mojojojo's picture
Level: Hangaround
Joined: Sun. Aug 14, 2005
Posts: 212 View posts
Location: Ecotopia
Posted by mojojojo: Wed. Jan 13, 2010 - 11:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:
Hard to say exactly. The generic parts of the named address space feature has been committed to mainline, which is HEAD, which is also future 4.5. Now this feature still needs to be ported to the AVR port. I don't know if it will be done in time for the general 4.5 release, but conceivably it could be done as an add-on patch to some 4.5.x release. A lot depends on how the work goes and available resources.

With 4.5 in "regression and doc fixes only" mode, it's not going to happen for 4.5; that's why I mentioned add-on patches, and time for the community members to get familiar with the model(s) involved.

I have no idea how hard that will be, but it seems clear to me that flash access will be the highest-leverage starting point. Almost everyone uses after all! Being able to have the compiler generate LPM/ELPM directly seems like it *should* be as simple as this gets. (But will that really be the case? Tune in later!)

EW wrote:
But I can tell you right now that it probably won't even be close to ready in the next 2 months.

Hope that helps.


Yes, it helps ... but I hardly expected it to be ready that soon! At this point I'm more just concerned that it be on the agenda for the not-hugely-distant future. Everyone's going to have to learn what this stuff is about. And I have this perverted preference for standards-based solutions, when they exist. :)

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98779 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Jan 13, 2010 - 12:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Everyone's going to have to learn what this stuff is about.

One would hope that the existing PROGMEM mechanism is never broken - a LOT of legacy code depends on it - while this feature will be great for simplifying newly written code (especially tables of strings!) there won't need to be a rush to understand any new mechanism as long as PROGMEM exists and is well documented.

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4934 View posts
Location: Rocky Mountains
Posted by EW: Wed. Jan 13, 2010 - 01:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
Approximately a half year ago, we have discussed this issue:

EW in https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=600427#600427 wrote:
wek wrote:

Well, assuming the yearly pace of gcc minor releases, and then a year to get things settled for avr-gcc, we are talking about two, maybe three years, plusminus. Correct?

Unfortunately, yes. I hope that we could actually move the date closer, perhaps cut that time in half. I would prefer a year to maybe a year and a half. But a lot of things have to go well for this to happen in that time frame.

And there are 2 differences between then and now:

- The named address space feature was on a GCC branch back then, and still being worked on. Now, it has been committed to mainline, and works on 2 ports.

- There are now more resources available to work on this feature.

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4934 View posts
Location: Rocky Mountains
Posted by EW: Wed. Jan 13, 2010 - 01:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojojojo wrote:

With 4.5 in "regression and doc fixes only" mode, it's not going to happen for 4.5;

Honestly I've had my head down because of multiple releases over the last few months. So it depends on what stage 4.5 is in. If they are preparing for a release soon-ish, then this feature will have to be a post-release patch.

mojojojo wrote:

I have no idea how hard that will be, but it seems clear to me that flash access will be the highest-leverage starting point. Almost everyone uses after all!

Yes, everyone has been wanting just this for many years.

mojojojo wrote:

Being able to have the compiler generate LPM/ELPM directly seems like it *should* be as simple as this gets. (But will that really be the case? Tune in later!)

The issue has been not so much generating the instructions, but to do it in such a generic way that it meets the stringent requirements of the GCC project, future C language standards, and it doesn't break any of the "middle" parts of GCC (which is the real tough nut). Luckily other people have now tackled this for us.

I've spoken in person to the people involved in writing this feature. I can tell you that it was difficult to get these patches committed. The approval process had many different rounds.

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4934 View posts
Location: Rocky Mountains
Posted by EW: Wed. Jan 13, 2010 - 01:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

One would hope that the existing PROGMEM mechanism is never broken - a LOT of legacy code depends on it - while this feature will be great for simplifying newly written code (especially tables of strings!) there won't need to be a rush to understand any new mechanism as long as PROGMEM exists and is well documented.

AFAIK, the existing PROGMEM mechanism should not be broken. Mainly because PROGMEM puts data into the Program Memory space and there are macros from avr-libc to retrieve the data.

I want the new system to look very much like how IAR does it on their compiler, including the same syntax. This should also help with migration.

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Wed. Aug 3, 2011 - 09:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, two years since https://www.avrfreaks.net/index.p... elapsed. I would like to ask the knowledgeable, what is the status now?

Btw., some of the PROGMEM stuff related to typedefs has been found being broken and the developers are planning to deprecate the typedefs in pgmspace.h. How does that fit into the plan exactly?

Jan

Top
SprinterSB
SprinterSB's picture
Level: Raving Lunatic
Joined: Thu. Dec 21, 2006
Posts: 2096 View posts
Location: Saar-Lor-Lux
Posted by SprinterSB: Wed. Aug 3, 2011 - 05:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
Okay, two years since https://www.avrfreaks.net/index.p... elapsed. I would like to ask the knowledgeable, what is the status now?

For the official FSF tree there is an enhancement PR at least: PR49868 ;-) Notice that there are two PRs depending on it.

wek wrote:
Btw., some of the PROGMEM stuff related to typedefs has been found being broken and the developers are planning to deprecate the typedefs in pgmspace.h.
PROGMEM on typedefs is not "broken"; it's never been documented in GCC. I thought we clarified that topic before already... PR38342

There is nothing to deprecate. However, deprecating, i.e. adding a deprecated attribute to types that have also progmem, will help you to write cleaner, more robust code. This could happen in avr-libc and I am encouraging it, see #33716.

You can, of course, still use it if you like but don't complain if a unsocumented feature does not work as you imagine (whatever that is).

PROGMEM, aka. __attribute__((progmem)), works very much like a section attribute. Notice that it is not possible to add section attribute to a typedef in C++ :-) For instance, it is not possible to attach progmem to a parameter or to auto. There is not really a "strong binding" between a variable and an attribute. The attribute rather says something about the symbol that's attached to a variable in static storage. Moreover, the waekness of attributes is the reason that the dreaded pgm_read_stuff is needed to get data out of .progmem again.

A Named Address Space acts very much like a qualifier (const, volatile and restrict are qualifiers you alredy know). With a qualifier, all the pgm_read_stuff will become superfluous, however all this is not easy to implement. Actually it is easy but it's hard to work around the severe limitations of AVR, in particular it's reduced addressing capabilities.

Declaring a variable in static storage with such a qualifier would put it in .progmem or one of it's subsections. However, there are things that cannot be expressed -- not with progmem nor with qualifier like

const char __pgm * const __pgm string2 = "hdjksdh";

None of the two lines will force the string literal into .progmem: it will end up in .rodata, i.e. in RAM. The only construct that could to that would be something like

#pragma avr progmem on
const char __pgm * const __pgm string3 = "litt";
#pragma avr progmem off

As for the implementation of named address space qualifier for AVR: contributors are welcome :-)

avrfreaks does not support Opera. Profile inactive.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98779 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Aug 3, 2011 - 05:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

it will end up in .rodata, i.e. in RAM.

If .rodata were used on an AVR why would it not be located in flash? (is this because of the need for LPM to access it later?)

Top
SprinterSB
SprinterSB's picture
Level: Raving Lunatic
Joined: Thu. Dec 21, 2006
Posts: 2096 View posts
Location: Saar-Lor-Lux
Posted by SprinterSB: Wed. Aug 3, 2011 - 05:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:
it will end up in .rodata, i.e. in RAM.
If .rodata were used on an AVR why would it not be located in flash? (is this because of the need for LPM to access it later?)
Yes. Suppose
char read_char (const char *p)
{
   return *p;
}

and you translate it using LPM instead of LD. Then write a caller in some other module

char caller (int val)
{
   char on_stack[20];
   sprintf (on_stack, "%d", val);
   return read_char (on_stack);
}

and you're broken. There are even simpler examples. You cannot tell if from a pointer alone and const may be added like here.

avrfreaks does not support Opera. Profile inactive.

Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Wed. Aug 3, 2011 - 05:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
As for the implementation of named address space qualifier for AVR: contributors are welcome :-)
Okay, I've asked of the status, so if I understand it well the named address spaces are nowhere by now. Don't get me wrong: I am not complaining.

Then I'd like to suggest to modify the typedefs in pgmspace.h simply by changing them to macros and/or removing the PROGMEM attribute from them as appropriate, rather than adding the deprecate attribute. The const qualifier might be perhaps added as appropriate. The rationale for this request is, that as an user I want to use distinct type names for variables that go to (and for pointers to such variables), and while I understand these are not implemented at the moment, I am willing to use them in the hope they will be at any point in the future, and I want my code to be compilable seamlessly with that future version, with the help of appropriately modified future pgmspace.h header.

As I don't like to be yelled at by the high esteemed avr-libc developers, I am not going to place this suggestion on the avr-libc forum, even if I know it belongs there. I am quite confident that most people who are involved will read and ignore it here too.

Jan

Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Wed. Aug 3, 2011 - 06:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
You cannot tell if from a pointer alone
You'd need to implement generic pointers as a distinct type from pointers to RAM and any other space. This is basically what the compilers aimed at 8-bit microcontrollers usually do. I know it is far from being simple and trivial.

JW

Top
SprinterSB
SprinterSB's picture
Level: Raving Lunatic
Joined: Thu. Dec 21, 2006
Posts: 2096 View posts
Location: Saar-Lor-Lux
Posted by SprinterSB: Wed. Aug 3, 2011 - 08:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
SprinterSB wrote:
You cannot tell it from a pointer alone
You'd need to implement generic pointers as a distinct type from pointers to RAM and any other space. This is basically what the compilers aimed at 8-bit microcontrollers usually do. I know it is far from being simple and trivial.
No, I don't need to implement it, it's already part of GCC :-) It's great work by Michael Meissner and IMHO it's a great loss that he no more works in that field. He made other very important changes; you'd never notice them without looking below GCC's surface, but they help GCC developers to easier write code. There is no immediate improvement of code produced by GCC, but the extensions help GCC in the long run to speed up development.
wek wrote:
SprinterSB wrote:
As for the implementation of named address space qualifier for AVR: contributors are welcome :-)
Okay, I've asked of the status, so if I understand it well the named address spaces are nowhere by now.
This is part of GCC now. The missing part between the named address support from Michael and the few lines in AVR part is just a marginality.

Somewhere I have a patch and I guess more guys played around with that feature already; atop of Michaels work it's straigh forward and just an exercise taking some hours.

avrfreaks does not support Opera. Profile inactive.

Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Wed. Aug 3, 2011 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you misunderstood my comment on generic pointers and I would like to discuss it further later. But before I add to the confusion, let's talk about this one first:

wek wrote:
Okay, I've asked of the status, so if I understand it well the named address spaces are nowhere by now.
SprinterSB wrote:
This is part of GCC now. The missing part between the named address support from Michael and the few lines in AVR part is just a marginality.

Somewhere I have a patch and I guess more guys played around with that feature already; atop of Michaels work it's straigh forward and just an exercise taking some hours.

Oh.

May I ask you to put this in work in a package, as it is now, so that we could play around with it? Please... :-)

Jan

Top
SprinterSB
SprinterSB's picture
Level: Raving Lunatic
Joined: Thu. Dec 21, 2006
Posts: 2096 View posts
Location: Saar-Lor-Lux
Posted by SprinterSB: Thu. Aug 4, 2011 - 01:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
SprinterSB wrote:
Somewhere I have a patch, and I guess more guys played around with that feature already; atop of Michaels work it's straigh forward and just an exercise taking some hours.
May I ask you to put this in work in a package, as it is now, so that we could play around with it? Please... :-)
Uploaded the respective patch:
http://gcc.gnu.org/bugzilla/show...

You can work around the IRA/reload glitches with -ffixed-26. See the PR for more details.

And it's just draft work, e.g. the device must have full LPM support.

Happy hacking!

avrfreaks does not support Opera. Profile inactive.

Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Thu. Aug 4, 2011 - 02:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks... but you know, I am not able to compile avr-gcc myself, so I hoped you will kindly provide the whole bunch ready to play with... please...

Jan

Top
SprinterSB
SprinterSB's picture
Level: Raving Lunatic
Joined: Thu. Dec 21, 2006
Posts: 2096 View posts
Location: Saar-Lor-Lux
Posted by SprinterSB: Thu. Aug 4, 2011 - 03:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't need to compile avr-gcc yourself, just let your computer do it for you ;-)

Currently there's too much broken, i.e. there is still support missing in the machine independant part to give a proper description of named AS. It makes no sense to supply tools where so much is broken, but the patch is a start for you. If you (or your PC) need help generating gcc/binutils/avr-libc just ask.

To work around the missing part you can do other expansion like using unspec or asm_operands. When I find time I'll that approach to overcome the current shortcomings and report.

avrfreaks does not support Opera. Profile inactive.

Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Fri. Aug 5, 2011 - 05:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
You don't need to compile avr-gcc yourself, just let your computer do it for you ;-)

If you (or your PC) need help generating gcc/binutils/avr-libc just ask.


I asked my PC and it told me that all it can do is to convert a bunch of 0s and 1s into another bunch of 0s and 1s... Honestly, this is not a trivial undertaking and while the compilation itself might run pretty much on its own, setting it all up until that happens is not that "automatic". For you, the difference might seem negligible, but for me, a BFU basically, it's a huge threshold and learning curve ahead. And, while I can justify playing with a new feature (with full acknowledgement of the experimental status of the things), knowing that I might want to use it in the future anyway, I can't justify the time and other resources and potential troubles associated with setting up a fully blown (avr-)gcc development workbench.

So, thanks for the offer, but no, thanks. If there's no easy way to play with it, I am not interested in the alpha testing.

Jan

Top
SprinterSB
SprinterSB's picture
Level: Raving Lunatic
Joined: Thu. Dec 21, 2006
Posts: 2096 View posts
Location: Saar-Lor-Lux
Posted by SprinterSB: Fri. Aug 5, 2011 - 07:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
I can't justify the time and other resources and potential troubles associated with setting up a fully blown (avr-)gcc development workbench.
Same for me for the resources.

A "GCC development worbench" typically consitst of a console and Emacs (for me) or vi. That's it. Forget about Eclipse or whatever fancy magic bullet/tool/gui/ide you thought of.

There is nothing for α-testing because there is no α-version yet. Regard it as development snapshot you can (or could) play with. Developers exchange patches, they don't shuffle distributions or binaries.

avrfreaks does not support Opera. Profile inactive.

Top