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
Buying IAR C
Started by ●January 11, 2008
Reply by ●January 13, 20082008-01-13
Reply by ●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 ●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 ●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 ●January 14, 20082008-01-14
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!
