From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22688 invoked by alias); 9 Feb 2011 05:26:33 -0000 Received: (qmail 22627 invoked by uid 22791); 9 Feb 2011 05:26:31 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,TW_CP,TW_LG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Feb 2011 05:26:24 +0000 Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p195QMPr004091 for ; Tue, 8 Feb 2011 21:26:22 -0800 Received: from pwi4 (pwi4.prod.google.com [10.241.219.4]) by hpaq7.eem.corp.google.com with ESMTP id p195QJFN013115 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Feb 2011 21:26:20 -0800 Received: by pwi4 with SMTP id 4so109207pwi.23 for ; Tue, 08 Feb 2011 21:26:18 -0800 (PST) Received: by 10.142.125.16 with SMTP id x16mr17946942wfc.385.1297229178707; Tue, 08 Feb 2011 21:26:18 -0800 (PST) Received: from coign.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) by mx.google.com with ESMTPS id v19sm1168106wfh.0.2011.02.08.21.26.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Feb 2011 21:26:18 -0800 (PST) From: Ian Lance Taylor To: ali hagigat Cc: gcc-help@gcc.gnu.org, david@westcontrol.com, thomas.martitz@student.htw-berlin.de Subject: Re: suggestion for GCC (1) References: Date: Wed, 09 Feb 2011 05:27:00 -0000 In-Reply-To: (ali hagigat's message of "Wed, 9 Feb 2011 08:24:07 +0330") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-02/txt/msg00161.txt.bz2 ali hagigat writes: > 1) What is a built-in function in gcc (and in the manual of gcc)? It is a function which gcc has special knowledge about. Many of the builtin functions start with __builtin_, such as __builtin_return_address. Others are defined in relevant language standards, such as memcpy. Others are widely used and are recognized when not in strict standard compliance mode, such as alloca. > Is it a function which its C/Assembly code is inside the code of the > compiler? Sometimes. > or Its code is some where on hard disk and inside a library > function? Sometimes. > or the code of the built in function is on hard disk but > when we build a program we do not need to link the library of that > function and the compiler automatically finds the code of that > function from a library function on hard disk and adds it to our > program automatically? Sometimes, if you treat the compiler linking against -lgcc and -lc by default to be automatically finding the code of the function. > 2) Ian said in one message that some supporting routine is necessary > for nested functions. What does a nested function mean? It means we > have a C function and then it calls another function inside by its > name? http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html > 3) Ian told that the functions like memcpy should be optimized and > they are target dependent and we do not make them as built in. It is > unacceptable in my opinion. The memcpy function is a builtin function by the definition above: gcc knows about it specially. In fact, memcpy is a special case in that gcc both recognizes it specially in source code, and gcc also generates calls to it in some cases. > We are talking about a great new feature for gcc, embedded programming > and writing firmwares, not optimization, which gives gcc a great power > and it is a new branch of programming. The fact that the code may be > slower or it takes more memory is a secondary trivial problem in this > case to me. gcc has supported embedded programming and writing firmware for many years, that is nothing new. It is the case that gcc always requires some supporting code when doing embedded programming. At the very least something has to load the program on the board and clear the BSS section. That supporting code has to also provide memcpy. Many people use the newlib and libgloss projects to provide this supporting code for embedded systems. See http://sourceware.org/newlib/ . > Besides compiler must be able to translate a code for a specific CPU, > why gcc is dependent to some thing except CPU?!!! Dependent to what? > (To me gcc has a bug which is dependent to some definitions outside > its code, It is a software issue which can be corrected) It is not a bug that a compiler requires supporting libraries. It is the normal case and it is true of all compilers. You are confusing the compiler proper, which is gcc, with a complete development system. A complete development system also includes an assembler, a linker, various libraries, a debugger, etc. gcc is just a compiler, not a complete development system. > 4) does gcc have any extension to produce stand alone code in open > source space you may aware of( for a free standing environment without > libraries). Not all by itself without any support, no. > 5) Ian said: > "The compiler does by default treat functions like memcpy as builtins, > and ..." > If memcpy is built in why gcc still generates some calls to memcpy > and memcpy should be provided some how as the manual of gcc says? Where does the manual say that? > 6) Where is memcpy at last? is it in libgcc, libc or it is built in? It in libc and it is builtin. > 7) Can i link only libgcc with my code in case of -nostdlib? and every > thing is OK? I write libgcc.a on my command line and every thing is > OK? No, you need more than that. > 8) When exactly compiler generates call to mem functions like memcpy, > memcmp, memset, memmove? Would you please write a complete list of the > cases when compiler does that for -nostdlib. Why the manual of gcc > does not talk about such an important subject. http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html If you find places where the documentation should be improved, I would encourage you to contribute a patch. Ian