On 2008-01-14, Hans-Bernhard Br�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