From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18063 invoked by alias); 13 Feb 2007 20:38:07 -0000 Received: (qmail 18051 invoked by uid 22791); 13 Feb 2007 20:38:06 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO elsdt-razorfish.arc.com) (194.202.198.226) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Feb 2007 20:37:59 +0000 Received: from elsdt-razorfish.arc.com (localhost.localdomain [127.0.0.1]) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11) with ESMTP id l1DKbkkY027653; Tue, 13 Feb 2007 20:37:46 GMT Received: (from joernr@localhost) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11/Submit) id l1DKbkT5027651; Tue, 13 Feb 2007 20:37:46 GMT Date: Tue, 13 Feb 2007 20:38:00 -0000 From: Joern Rennecke To: Doug Evans Cc: cgen@sources.redhat.com Subject: Re: delayed branches and zero overhead loops Message-ID: <20070213203746.GA16492@elsdt-razorfish.arc.com> References: <20070213153717.GA12710@elsdt-razorfish.arc.com> <17874.4229.806002.475024@casey.transmeta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17874.4229.806002.475024@casey.transmeta.com> User-Agent: Mutt/1.4.1i Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00040.txt.bz2 On Tue, Feb 13, 2007 at 11:24:53AM -0800, Doug Evans wrote: > It sounds like you want to add an application specific entry to the > cpu description file. For me that's an ipso-facto wrong way to go. This is something only of concern to applications that care about the semantics of the insns. Thus, gas does not need to know about this. If you wanted to generate a gcc machine description, than this is in principle relevant - except that expressing this all in generic rtl would likely lead the machine description generator to give up, since it won't be able to find any basic arithmetic instructions - every instruction will be flagged as having conditional flow control. > Having said that, I can imagine partitioning the description file > into multiple files such that these pseudo-insns are only seen by > the application in question. Why does it have to be yet another file? There is already a syntax-only attribute that specifies that some information is only for applications that care about syntax. Not that I am fundamentally opposed to doing it with separate files, but it appears to me that it makes things core complicated rather than simpler. If you want it to frame it in terms that give universal meaning to the instruction semantics, you can express it in three pieces: - A piece of rtl that might need to be appeded to the semantics of every instruction. - A condition that tests if this piece of rtl should actually be executed, for use in a simple interpreter. - In the mloop.in:xextract-pbb code, code that computes at decode time when to append the pseudo insn to a pbb (or if you have some other use for a pseudo insn that doesn't end a pbb, you might also stick it into the middle). > Thus question: Is there a way to express the zero-overhead > loops in an a way that is more faithful to being just a > description of the architecture, and not an application specific hack. As I said above, you can do it by adding rtl to every instruction that makes every instruction COND_CTI. > Which leads to me next question: > Is ARCompact a variant of the ARC for which I did a port ages ago? Unfortunately, the sourceware.org cvs history is a bit patchy - e.g. the bfd cvs history only goes back to 1999 - so I'm not sure which part(s) of the toolchain you ported, and to what ARC variant. ARCompact is the instruction set architecture used by the ARCtangent-A5, ARC 600 and ARC 700 cores. It has 16 and 32 bit opcodes. The ARCtangent-A4 had only 32 bit opcodes, but I have been told that for user code, ARCcompact is mostly backwards ompatible to ARCtangent-A4 code. > I forget if/how it handled zero overhead loops. > Can you refresh my memory? That might help in coming up with > a reasonable solution. The loop counter register lp_count is a core register, which means you can do with it most of the things you can do with a general purpose register. lp_start and lp_end are auxilary registers, which are usually set up with the lp / lpcc instruction althou they can also be read and written to with the lr and sr (load / store auxilary register) instructions. The lp instruction set lp_start to the sucessor instruction, and lp_end to the instruction specified by the offset embedded in the isntruction. likewise for lpcc if the condition is true. If the condition is false, lpcc will instead jump to the loop end (that is the same address that would otherwise be laoded int lp_end). lp_end points to the first instruction after the loop. When the program counter is incremented to match lp_end, lp_count is decremented; if lp_count was not 1 (i.e. it is not decremented to zero), a jump to lp_start is performed. The ARC 700 also as a loop inhibit bit in its status register that gets set on interrupt, and cleared by the lp / lpcc instruction.