From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16147 invoked by alias); 29 Oct 2003 16:50:32 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 16138 invoked from network); 29 Oct 2003 16:50:30 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Oct 2003 16:50:30 -0000 Received: from toenail.toronto.redhat.com (toenail.toronto.redhat.com [172.16.14.211]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 01836800337; Wed, 29 Oct 2003 11:50:29 -0500 (EST) Received: from toenail.toronto.redhat.com (IDENT:fche@localhost [127.0.0.1]) by toenail.toronto.redhat.com (8.12.8/8.12.5) with ESMTP id h9TGoSIk031739; Wed, 29 Oct 2003 11:50:28 -0500 Received: (from fche@localhost) by toenail.toronto.redhat.com (8.12.8/8.12.8/Submit) id h9TGoSXK031737; Wed, 29 Oct 2003 11:50:28 -0500 Date: Wed, 29 Oct 2003 16:50:00 -0000 From: "Frank Ch. Eigler" To: Ralph Escherich Cc: cgen@sources.redhat.com Subject: Re: binutils porting to new CPU Message-ID: <20031029165027.GA30779@redhat.com> References: <200310281821.24902.esche@mobilesmartsinc.com> <20031029024802.GA9756@redhat.com> <200310290839.13951.esche@mobilesmartsinc.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <200310290839.13951.esche@mobilesmartsinc.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-q4/txt/msg00017.txt.bz2 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1269 Hi - > [...] > Do you have a more detailed API description of what is generated and > how it should be used for porting the binutils? [...] There isn't a really good list, I'm afraid. None of those who have built a complete port took the extra time to document all the steps and nuances. It's all rather vernacular: start based on an existing port, do a massive search & replace for a new port name, ask here when you run into trouble. A simple port may go smoothly enough not to need any help. > Also gas/cgen.c contains code for fixups and parsing. How does all > this fit into the big picture of porting binutils to a new cpu target? It's a necessary detail. The fewer addressing modes your target supports, and the simpler the layout of the operands that parametrize any given address, the simpler (to almost nonexistent) these functions can be. > How do fixups and frags ??? fit into the API? [...] They barely do. Some CGEN operand parsing functions plop fixups into the assembler, for ultimate disposition as an assembly-time constant, or emission as a link-time relocation. Frags are little partially-filled-in byte strings that are concatenated ultimately to form object code. All this is deep GAS/BFD magic, not really cgen related. - FChE --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/n+/SVZbdDOm/ZT0RAmBiAJ9kULGeR/wHdJriKxo/xOHm9TO7RACfYPf6 s+tidOPVkYF1mWFRF3DmAyY= =rMXI -----END PGP SIGNATURE----- --ibTvN161/egqYuK8--