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

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

Re: [avr-libc-dev] Re: Revised release criteria for GCC 4.0


From: Bernardo Innocenti
Subject: Re: [avr-libc-dev] Re: Revised release criteria for GCC 4.0
Date: Sun, 19 Dec 2004 21:37:19 +0100
User-agent: Mozilla Thunderbird (X11/20041216)

E. Weddington wrote:
Bernardo Innocenti wrote:

Integrating simulavr so we could run GCC's regression tests
on the AVR would be great (mainline no longer broken every
few weeks without anyone noticing).

I think it would be great to integrate simulavr, or now known as simulavrxx (even though it is just an internal architecture change, there is new management at the simulavr project), and also integrate avarice. But also most importantly I would like to have a native Win32 version of both of those.

You mean built with mingw or just not using cygwin1.dll?
The latter is certainly possible by configuring in uberbaum
with --target=avr, --host=i386-pc-mingw32 and --build=i386-pc-cygwin.

That would be a canadian-cross build, which may uncover bugs in
the build infrastructure.  Gunther Nikl uses it to build the
m68k-*-amigaos toolchain.


If only I knew about that a few months ago... We almost
rewrote Atmel's bootloader application-note which was based
on IAR's compiler and used a MS Excel document with VBA
macros as a replacement for autoconf :-)

Well, that's what documentation is for. ;-) See the avr-libc user manual for more info.

It's too bad Google didn't find it for me... Maybe that
would be a good reason for making avr-libc documentation
available online? :-)


If these could be made a little more generic, they would be
very useful on many Harvard processors.  The RTEMS people
may like to have something like that in newlib.

I don't know how generic it could be made until GCC actually has a generic way of specifying different memory spaces. Right now those routines make use of macros in avr-libc to access (read) the program memory space of the AVR.

Even with GCC support, functions woud have to be built twice and
made available with and without the _P suffix (in C++ we could have
used overloading).

This is a trick I use in our projects to prevent massive code
duplication, while abstracting the CPU type:

--- BEGIN Makefile ---
[...]
kfront_CSRC = \
        [...lots of stuff here...] \
        mware/formatwr.c mware/sprintf.c mware/text_format.c
kfront_PCSRC = \
       mware/formatwr.c mware/sprintf.c mware/text_format.c
[...]
--- END Makefile ---


--- BEGIN rules.mk ---
[...]
$(1)_PCOBJ   = $$(foreach 
file,$$($(1)_PCSRC:%.c=%_P.o),$$(OBJDIR)/$(1)/$$(file))
[...]
# Generate special progmem variant of a source file
$$($(1)_PCOBJ) : $$(OBJDIR)/$(1)/%_P.o : %.c
       $L "$(1): Compiling $$< (PROGMEM)"
       @$$(MKDIR_P) $$(dir $$@)
       $Q $$(CC) -c -D_PROGMEM $$(CFLAGS) $$($(1)_CFLAGS) $$< -o $$@
--- END rules.mk ---


--- BEGIN compiler.h ---
[...]
    #elif CPU_AVR
         /* Support for harvard architectures */
         #ifdef _PROGMEM
             #define PGM_READ_CHAR(s) pgm_read_byte(s)
             #define PGM_FUNC(x) x ## _P
             #define PGM_ATTR  PROGMEM
         #endif
    #endif

[...]

/* Support for harvard architectures */
#ifndef PSTR
#define PSTR            /* nothing */
#endif
#ifndef PGM_READ_CHAR
#define PGM_READ_CHAR(s) (*(s))
#endif
#ifndef PGM_FUNC
#define PGM_FUNC(x) x
#endif
#ifndef PGM_ATTR
#define PGM_ATTR        /* nothing */
#endif
[...]
--- END compiler.h ---


--- BEGIN mware/text_format.c ---
[...]
/*!
* Render string \a str in Bitmap \a bm at current cursor position
*
* \note Text formatting functions are also available with an _P suffix
*       accepting the source string from program memory.  This feature
*       is only available (and useful) on Harvard microprocessors such
*       as the AVR.
*
* \see text_putchar()
*/
int PGM_FUNC(text_puts)(const char * PGM_ATTR str, struct Bitmap *bm)
{
        char c;

        while ((c = PGM_READ_CHAR(str++)))
                text_putchar(c, bm);

        return 0;
}
[...]
/*!
* vprintf()-like formatter to render text in a Bitmap.
*
* Perform vprintf()-like formatting on the \a fmt format string using the
* variable-argument list \a ap.
* Render the resulting string in Bitmap \a bm starting at the current
* cursor position.
*
* \see text_puts() text_putchar() text_printf()
*/
int PGM_FUNC(text_vprintf)(struct Bitmap *bm, const char * PGM_ATTR fmt, 
va_list ap)
{
        return PGM_FUNC(_formatted_write)(fmt, (void (*)(char, void 
*))text_putchar, bm, ap);
}
[...]
/*!
* Return the width in pixels of a vprintf()-formatted string.
*/
int PGM_FUNC(text_vwidthf)(UNUSED(struct Bitmap *, bm), const char * PGM_ATTR 
fmt, va_list ap)
{
        return PGM_FUNC(vsprintf)(NULL, fmt, ap) * FONT_WIDTH;
}
--- END mware/text_format.c ---


A similar technique could be used in newlib/libgloss.


Ralf, Bernie, you both have had more experience with newlib than I have, does all of this sound reasonable? Is there anything that we're not thinking of here?

- newlib and avr-libc have different licenses, altough it seems
 newlib already includes a few GPL'd files in their codebase
 and many avr-libc sources still bear the 3-clause BSD license
 header.

*All* of the avr-libc sources now have the 3-clause BSD license.

That's good, it should be compatible with newlib then.

- newlib uses a funny documentation format, avr-libc uses doxygen;


I'm perfectly willing to drop doxygen. In my mind it is too restrictive. Joerg will have to state his opinion.

The fancy documentation tool used in newlib appears to follow
Doxygen's philosophy, while using an ugly syntax.  I've never
seen what the formatted output looks like, but I'd bet it's not
on par with Doxygen's.

libstdc++ already uses Doxygen, so I'd rather adapt newlib
than avr-libc.

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/





reply via email to

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