avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Program memory macros and -mint8


From: E. Weddington
Subject: Re: [avr-libc-dev] Program memory macros and -mint8
Date: Mon, 11 Nov 2002 10:00:00 -0700

On 11 Nov 2002 at 16:16, Joerg Wunsch wrote:

> As Nils Kristian Strom wrote:
> 
> > I have written program memory macros that uses (void*), (char*) etc.
> > to hold the address, which works flawlessly for both -mint8 and 16
> > bit integers.
> 
> I think they should be rewritten using explicit integer sizes instead.
> The use of pointers is IMHO OK here, but instead of using char *,
> rather use uint8_t *, etc.
> 
> Theodore has been proposing something similar for the EEPROM functions
> recently.  He also uses explicit integer sizes.
> 
> Of course, <inttypes.h> needs my suggested fix applied first.  Any
> comments about that one?
> 
> > Are there any issues I fail to understand ?
> 
> Nope, except what i've been mentioning all the time: it needs a
> volunteer to do all this.  avr-libc simply has never been designed
> with the idea of using -mint8 in mind, so if you now find -mint8
> flaws, most of them are not there intentionally but rather
> accidentally.
> 
> Of course, -mint8 will always violate the C standard, but if someone
> really cares for all the details of it, avr-libc could be probably
> made largely compatible with it (and the parts that are incompatible
> simply need to be documented then).
> 

As an argument for -mint8 compatibility, this actually might help 
make more optimal code especially in the expressions where automatic 
promotion to 16-bit integer makes suboptimal code. Specifying -mint8 
might allow the user to optimize their code without having to 
liberally sprinkle unsigned char typecasts throughout their code.

If having -mint8 compatibility is a future goal, at least what about 
defining the method of doing first, like getting <inttypes.h> fixed 
per Joerg, and then have a policy of any new code added be -mint8 
compatible. Then, the current code can be fixed up over time.

I certainly don't see any -mint8 compatibility by a 1.0 release. 
Perhaps 6 months after that release.....

My 2 centavos.

Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]