Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes

[Joerg Wunsch]

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. ;-)