From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1034 invoked by alias); 10 Jun 2010 17:21:13 -0000 Received: (qmail 962 invoked by uid 22791); 10 Jun 2010 17:21:12 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,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; Thu, 10 Jun 2010 17:21:05 +0000 Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o5AHL2s5018072 for ; Thu, 10 Jun 2010 10:21:03 -0700 Received: from pvg16 (pvg16.prod.google.com [10.241.210.144]) by hpaq6.eem.corp.google.com with ESMTP id o5AHL0UD023860 for ; Thu, 10 Jun 2010 10:21:01 -0700 Received: by pvg16 with SMTP id 16so99109pvg.33 for ; Thu, 10 Jun 2010 10:21:00 -0700 (PDT) Received: by 10.140.55.13 with SMTP id d13mr347357rva.119.1276190459874; Thu, 10 Jun 2010 10:20:59 -0700 (PDT) Received: from coign.google.com (dhcp-172-22-126-240.mtv.corp.google.com [172.22.126.240]) by mx.google.com with ESMTPS id r23sm211566rvq.12.2010.06.10.10.20.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Jun 2010 10:20:58 -0700 (PDT) To: "Radu Hobincu" Cc: gcc@gcc.gnu.org, "Petronela Agache" Subject: Re: GCC porting questions References: <38232.141.85.94.100.1276182650.squirrel@www.arh.pub.ro> From: Ian Lance Taylor Date: Thu, 10 Jun 2010 18:06:00 -0000 In-Reply-To: <38232.141.85.94.100.1276182650.squirrel@www.arh.pub.ro> (Radu Hobincu's message of "Thu\, 10 Jun 2010 18\:10\:50 +0300 \(EEST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg00405.txt.bz2 "Radu Hobincu" writes: > I have written here a few weeks ago regarding some tutorials on GCC > porting and got some very interesting replies. However, I seem to have > gotten stuck with a couple of issues in spite of my massive Googling, and > I was wondering if anyone could spare a couple of minutes for some > clarifications. > > I am having troubles with the condition codes (cc_status). I have looked > over a couple of architectures and I do not seem to understand how they > work. > > The machine I am porting GCC for has 1 4bit status register for carry, > zero, less than and equal. I do not have explicit comparison instructions, > all of the ALU instructions modify one or more flags. > > What I figured out so far looking over AVR and Cris machine descriptions > is that each instruction that modifies the flags contain an attr > declaration which specify what flags it is changing. Also, there is a > macro called NOTICE_UPDATE_CC which sets up the cc_status accordingly by > reading this attr. This is the part of the code I do not understand. There > are certain functions for which I could not find any descriptions, like > "single_set" and macros like "SET_DEST" and "SET_SRC". Also, looking over > conditions.h, I see that the CC_STATUS structure contains 2 rtx fields: > "value1" and "value2", and also an int called "flags". What do they > represent? Is "flags" the contents of the machine's flag register? For a new port I recommend that you avoid cc0, cc_status, and NOTICE_UPDATE_CC. Instead, model the condition codes as 1 or 4 pseudo-registers. In your define_insn statements, include SET expressions which show how the condition code is updated. This is how the i386 backend works; see uses of FLAGS_REG in i386.md. As far as things like single_set, SET_DEST, and SET_SRC, you have reached the limits of the internal documentation. You have to open the source code and look at the comments. Similarly, the description of the CC_STATUS fields may be found in the comments above the definition of CC_STATUS in conditions.h. Ian