Reply by Grant Edwards January 14, 20082008-01-14
On 2008-01-14, Hans-Bernhard Br&#2013266166;ker <HBBroeker@t-online.de> wrote:

>> 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. > > 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." -- Grant Edwards grante Yow! I predict that by at 1993 everyone will live in visi.com and around LAS VEGAS and wear BEATLE HAIRCUTS!
Reply by January 14, 20082008-01-14
Grant Edwards wrote:

> I don't really understand. Are you saying that gcc is > sometimes written to use an existing libgcc?
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.
> 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.
Their ABI does limit GCC's choice of ABI for all external functions.
Reply by CBFalconer January 14, 20082008-01-14
Grant Edwards wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote: > >> 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. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
Reply by Grant Edwards January 13, 20082008-01-13
On 2008-01-14, CBFalconer <cbfalconer@yahoo.com> wrote:

> 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. -- Grant Edwards grante Yow! .. Am I in a SOAP at OPERA?? visi.com
Reply by CBFalconer January 13, 20082008-01-13
msg wrote:
> Grant Edwards wrote: >> CBFalconer <cbfalconer@yahoo.com> wrote: >>
... snip ...
>> >>> In general, basic libraries for compilers are particular to >>> that compiler on that device. >> >> I guess I just wouldn't include libc in the category of "basic >> libraries that are particular to a compiler/device". > > 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'.
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. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
Reply by Ulf Samuelsson January 13, 20082008-01-13
> Would it be possible to questimate the code size IAR generates in > comparison > with ICCAVR? I have a project which completely fills an ATMega162 and I > would like to have some space for extra features without a hardware > redesign. > > Meindert >
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. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Reply by Grant Edwards January 13, 20082008-01-13
On 2008-01-13, msg <msg@_cybertheque.org_> wrote:

> Granted, Grant <g>, 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.
Agreed. A particular implimentation of libc might be device specific, and might also be written using compiler extensions so that it's compiler specific. -- Grant Edwards grante Yow! I'm RELIGIOUS!! at I love a man with visi.com a HAIRPIECE!! Equip me with MISSILES!!
Reply by msg January 13, 20082008-01-13
Grant Edwards wrote:

> On 2008-01-13, msg <msg@_cybertheque.org_> wrote: > > >>>>In general, basic libraries for compilers are particular to >>>>that compiler on that device. >>> >>>I guess I just wouldn't include libc in the category of "basic >>>libraries that are particular to a compiler/device". >> >>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'. > > > 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 <g>, 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
Reply by Grant Edwards January 13, 20082008-01-13
On 2008-01-13, msg <msg@_cybertheque.org_> wrote:

>>>In general, basic libraries for compilers are particular to >>>that compiler on that device. >> >> I guess I just wouldn't include libc in the category of "basic >> libraries that are particular to a compiler/device". > > 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'.
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. -- Grant Edwards grante Yow! If I pull this SWITCH at I'll be RITA HAYWORTH!! Or visi.com a SCIENTOLOGIST!
Reply by msg January 13, 20082008-01-13
Grant Edwards wrote:

> On 2008-01-13, CBFalconer <cbfalconer@yahoo.com> wrote: > > >>>I give up. I thought the thread was about compilers. >> >>In general, basic libraries for compilers are particular to >>that compiler on that device. > > > I guess I just wouldn't include libc in the category of "basic > libraries that are particular to a compiler/device".
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