Oh well, yet another mass followup. Sorry if that's messing up your thread displays. ;-)
As Szikra Istvan wrote: > >I'd prefer those functions to be in <util/*> than <avr/generic/*>. > Me too and, if it avr specific than rather <avr/util/*> than > <avr/generic/*> As that still has the problem of adding another level of subdirs, there doesn't seem to be much love for this here. > i also suggest moving <avr/io?*.h> to something like > <avr/ios/io?*.h> since noone (supposed) using them Well, perhaps. But that's not an API change (as avr/io?*.h are not official part of the API), so that could be done at any time. As there's more agreement to avoid an additional level of subdirectories, I wouldn't rush that. > by the way i suggest to do something (maybe merging) interrupt.h and > signal.h (to isr.h or interrupt.h) That has already been suggested anyway, I'd prefer using avr/interrupt.h over establishing yet another new header. As Darcy Watkins wrote: > I did some more work on an experimetal utility to parse the part > description XML files from AVRStudio into device specific include > files. Umm, but you know that Atmel already ships such a utility as part of AVR Studio, do you? Unfortunately, it's Windows-only, and as it apparently uses Microsoft's XML library, it cannot even be made run easily under the Wine emulator. But it can generate the skeleton of GCC/avr-libc header files. > Unfortunately there are a few descrepancies in naming since Atmel > shorten some of the names such as: > OVERFLOW ==> OVF > COMPARE ==> COMP > INTERRUPT ==> INT Yes, and I'd like to go with the shorter names in future, as they match both the XML files and the datasheet (well, occasionally, the datasheet uses a space within a name that got replaced by an underscore in the XML files), as well the names used by IAR. I don't want to abandon our old SIG_xxx names immediately, and I wouldn't even deprecate them right now, but rather actively start propagating the "new" names. I also think of a solution that would semi-automatically parse the names and descriptions into a doxygen file, so they will finally be documented including together with the device they belong to. As Szikra Istvan wrote: > >So e.g., SIG_INTERRUPT0 would get an alias named INT0_vect. > this is good either, but the prefixes has the advantage of better > usage of intellisense/autocomplete... (SIG_<ctrl+space>) Sorry for that, but I'm definately settled for the FOO_vect names to ease portability between our code and IAR. With the FOO_vect names, I could eventually contribute something like <compat/iar4.h> that allows writing fully compatible source code without the need to reinvent the wheel for this over and over again. As Dave Hansen wrote: > Has anyone put any thought into how we might get avr-gcc to do > something other than silently generate incorrect code when the user > specifies an incorrect SIG_* (or *_vect) symbol? Marek already did, but I think it's only available starting with GCC 4.x. The compiler generates a warning when it sees a function that has the interrupt or signal attribute, yet where the name doesn't start with __vector. As E. Weddington wrote: > - I like Zane's idea of ISR() too. There. Let's implement it! :-) > Along with deprecating SIGNAL() and INTERRUPT(). OK. > - I like isr.h too. Combine interrupt.h and signal.h. I'd prefer interrupt.h (though won't insist on it). The name is descriptive enough, and it contains more than just the ISR handling (like the macros to enable/disable interrupts). > - I like migrating the names to the same as in the AVR Studio XML > files. It will definitely help in winning over IAR users. ;-) Hihi. :) As Marek Michalkiewicz wrote: > > - I do like the idea that Royce has (above) about naming the ISR > > function any name. However, I agree with Joerg, in that it would > > take an awful lot of effort. Perhaps someday, but not now. > Probably not that awful :) - see how it is done in the msp430 port. I didn't doubt it could be done, but I'm afraid of the API change. With only you and Björn actively committing to GCC and binutils, and the need to coordinate an API change in GCC with the respective changes in avr-libc, that's too much effort for me for too little win. Actually, the only win is that there are no silly __vector_* names anymore in the binary (and thus in the debugger). I'd rather see that energy spent into optimizing ISRs so the compiler could effectively issue a `naked' ISR automatically for things like: ISR(XXX_vect) { PORTB |= _BV(4); } (No __zero_reg__ needed, not even SREG will be changed. No pushes, no pops needed.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list