From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8148 invoked by alias); 8 Sep 2002 17:53:37 -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 8141 invoked from network); 8 Sep 2002 17:53:36 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 8 Sep 2002 17:53:36 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id KAA16879; Sun, 8 Sep 2002 10:53:33 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma016871; Sun, 8 Sep 02 10:53:26 -0700 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id g88HrTj05786; Sun, 8 Sep 2002 10:53:29 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id KAA20622; Sun, 8 Sep 2002 10:53:29 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15739.36505.358995.624786@casey.transmeta.com> Date: Sun, 08 Sep 2002 10:53:00 -0000 To: Shehryar Humayun Cc: cgen@sources.redhat.com Subject: Re: C-style assembly In-Reply-To: <20020908171322.37725.qmail@web21210.mail.yahoo.com> References: <15738.51201.76375.295958@casey.transmeta.com> <20020908171322.37725.qmail@web21210.mail.yahoo.com> X-SW-Source: 2002-q3/txt/msg00069.txt.bz2 Shehryar Humayun writes: > > No effort has been put into supporting C style > > assembly language. > Is this due to lack of expression in RTL or is it the > cgen implementation that has been constrained with > supporting only a specific assembly syntax (i.e. > mnemonic opr1, opr2)? It's due to lack of desire for supporting arbitrary (in the general case) assembler syntaxes. It's time best spent elsewhere IMO. > Correct me if I am wrong, I am asking this because I > think that if the cause is lack of RTL's expression, > then the escape hatch of emitting c-code in .cpu files > can be used; I don't understand how this is useful. The issue here is providing something to gas that let's it _parse_ (pseudo) c-code (i.e. the incoming assembly). Also, RTL isn't really relevant here. What is relevant is the assembler syntax string that can be specified along with the RTL. Or maybe that's what you meant? > and if the cgen's implementation is a > constraint, then the .scm files can be manipulated to > understand c-code, right? There are two related issues here. The first is how the assembler syntax is represented in the .cpu file. The second is the assembler syntax that gas accepts. Normally these issues are the same, the assembler syntax in the .cpu file is just a template of the gas syntax. I only mention this as maybe there's a way of solving this by having a different assembler syntax in the .cpu than what gas accepts. More to the point ... There's a fundamental property of all gnu tools that one always takes into consideration when doing design: target specific code does not belong with target-independent code. [there are exceptions, though even those are generally treated carefully] In other words, if special code is needed to support a particular target, then that code belongs with the rest of the code associated with that target, and not with the core of the tool itself. In this case, I _think_ there isn't enough of a compelling reason to add a whole bunch of code to cgen proper just to support C-style assembler syntax. The best way to engineer a solution here is to keep as much of the code out of the .scm files as possible and instead keep it with the target. > > If you want to use cgen's assembler support, > > I suggest writing the .cpu using "normal" assembly > > syntax and > > write a separate program(/library) that converts > > C-style to normal-style. Doing this is one way of keeping all target-specific code with the target and out of cgen proper. Maybe there is a reasonable way to add C-style assembler syntax support directly to cgen. I fear however that it's a slippery slope and best avoided. One target's c-style assembly syntax isn't necessarily similar to another's, and I _think_ supporting all of them in cgen proper will lead to a big mess really quick. Best to solve this problem outside of cgen.