Buying IAR C

They are not exclusively tied to GCC, but (apart from Newlib) primarily meant to run on Linux, which is tied to GCC. They are typically supplied with prebuilt GCC packages. If these libraries didn't exist it would not be possible to use GCC or Linux. That's why I call them "GCC libraries".

We were talking about code size (ie. size of application) which includes the libraries. On embedded systems the libraries are as important as the compiler as they take a significant proportion of the total codesize. It's also much easier to halve the size of libraries than to make a compiler emit much smaller code, so it is one of the first things people optimise.

Wilco

In general, basic libraries for compilers are particular to that compiler on that device. The reason is that all compilers need some routines that cannot be written (portably) in the language itself. One example is the malloc/realloc/free/calloc package in C.

Usually preparing a program calling those routines requires no special action. [1] The library is routinely searched at some point, and the necessary modules loaded.

avrlibc is not part of the avr port of gcc - but for most practical purposes, it is closely tied. The library uses gcc-specific extensions, and is thus not directly usable with any other compiler, and while avr-gcc users may well use other libraries in addition, I doubt if there are many that don't also use avrlibc. However, it *is* possible to avoid using it - for example, support functions for gcc-generated code are part of the gcc port libraries rather than avrlibc. The maintainance, development, support and documentation of the avr gcc port and the avrlibc library are strongly intertwined.

The C standards define both the language and certain library functions, making it difficult to separate them entirely. From the users viewpoint, a toolchain consists of (at least) a compiler, assembler, linker, and library - each is virtually useless without the other. It is thus important that library implementations are considered when comparing toolchains, at least for the sort of functions that are going to be used (i.e., for most small embedded systems you can ignore big, slow printf's or malloc's, because they are not used anyway).

mvh.,

David

I guess I just wouldn't include libc in the category of "basic libraries that are particular to a compiler/device".

I've used several cross compilers that didn't come with a libc implementation. Usually when I build a gcc cross compiler, it doesn't include libc, and quite a few of my projects don't use libc.

What I would call "basic libraries" would be just those required for the compiler to produce executable code. In the case of gcc, that's libgcc. Comparing one libc implementation with another is a useful enough thing to do, but let's not conflate it with comaring one _compiler_ with another. You can mix and match compiler and libc just as you can compiler and debugger or compiler and editor.

A compiler doesn't needs malloc/realloc/free/calloc. I don't use them on embedded systems, so it would seem to be the user that needs them not the compiler.

What would you call (name) the library that contains 'getch', 'putch' and friends then? I suppose its name isn't particularly relevant except that convention is 'libc'.

Michael

I'd call it 'libc'. I just wouldn't refer to it as part of the compiler or as a basic library required by the the compiler. It's a library just like any other with the distinction that it's defined by a particular standard.

Many of my projects have nowhere to 'getch' a character from nor anywhere to 'putch' a character to. If those routines were required by the compiler then I couldn't be using the compiler for those projects. Yet I am.

Granted, Grant , but I was replying to your comment: "I guess I just wouldn't include libc in the category of 'basic libraries that are particular to a compiler/device'", with the emphasis on 'device'; IOW, device specific code resides therein, and isn't likely portable as-is between toolchains and other devices.

Regards,

Michael

Agreed. A particular implimentation of libc might be device specific, and might also be written using compiler extensions so that it's compiler specific.

You can get a 4 kB limited version of the IAR compiler for free. You can get a 30 day evaluation version for free as well. If you are using ICCAVR, then there should be some room for improvement. A very good feature of the IAR compiler is the ability to optimize global variables into the lower bank of registers. It allowed me to reduce code from 5 kB to below 4 kB in one important application.

With the ATmega164P providing 2 serial ports there are IMHO very few reasons to use the ATmega162 Existing design (like yours) and need of the external bus. The ATmega164P has a migration path to m324P and m1284P.

... snip ...

Not a part of the C system. Those functions don't exist in ISO standard C, therefore there is no need for them in the standard library. However getc and putc are standard specified, and must be in the associated library.

One of the problems (or advantages) with gcc is that it often uses a pre-existing library. This means that the gcc code generation is naturally limited to the same sort of sequences as was used for that library. Cross-compiler systems won't have this problem.

I don't really understand. Are you saying that gcc is sometimes written to use an existing libgcc? If you're talking about libc (or other external libraries), I don't see how they would limit the design of gcc's code generation.

Just as examples, consider two things. The order of parameter passing (assuming all passed on the stack) and the format of the stack marker.

Most C systems pass parameters in the reverse order to that in the source, so that the first parameter is on top of the stack when received. This is done to simplify variadic functions, such as printf. However, there is no real reason not to pass them in the normal order for non-variadic functions, or to pass a final extra value specifying the size of the overall parameter pass section.

Another thing is the stack marker. This normally contains a pointer to the previous stack marker, a return address, and parameters, all in some known order. This is insufficient for some languages that allow for nested procedure scopes, such as Pascal. So the design has to account for this. Note that it is not machine, but language, dependant.

So, going along with the mob allows reuse of library modules. Making these things optimum for the actual language/system can very well require new libraries.

No. It's expressly designed to be able to work with an existing libc. For quite a while, the single most wide-spread use case for GCC was as a replacement for Unix systems that lacked a usable, standards-compliant C compiler (rather than the crippled cc coming with the OS that could compile hardly anything besides the kernel). As these systems did come with a (sometimes quirky, but generally usable) libc, GCC was designed to use that.

Their ABI does limit GCC's choice of ABI for all external functions.

Of course. That I knew. The ABI would have to be compatible with any extant libraries that were to be called. I just did't parse that from this

"This means that the gcc code generation is naturally limited to the same sort of sequences as was used for that library."