From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30999 invoked by alias); 13 Feb 2007 21:00:20 -0000 Received: (qmail 30937 invoked by uid 22791); 13 Feb 2007 21:00:12 -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 21:00:00 +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 l1DKx54O028059; Tue, 13 Feb 2007 20:59:05 GMT Received: (from joernr@localhost) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11/Submit) id l1DKx55B028057; Tue, 13 Feb 2007 20:59:05 GMT Date: Tue, 13 Feb 2007 21:00:00 -0000 From: Joern Rennecke To: "Frank Ch. Eigler" Cc: cgen@sources.redhat.com Subject: Re: delayed branches and zero overhead loops Message-ID: <20070213205905.GB16492@elsdt-razorfish.arc.com> References: <20070213153717.GA12710@elsdt-razorfish.arc.com> <20070213185118.GA20088@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070213185118.GA20088@redhat.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/msg00041.txt.bz2 On Tue, Feb 13, 2007 at 01:51:19PM -0500, Frank Ch. Eigler wrote: > Hi - > > > The ARCompact architecture has delay slots and zero overhead loops. > > I see that there is already a cgen simulator with delay slots, for > > the iq2000. I've looked at its mloop.in xextract-pbb case [...] > > For what it's worth, my recollection about how the PBB stuff works is > so hazy that I won't be able to give quick good advice. Have you > considered using a plain non-pbb kernel, where you can hand-code these > subtleties in plain C/C++ code? Yes, I have. In fact I though for a while that pbb was plain impossible, because I had a part of the instruction length calculation in the semantics, but that left me uncomfortable because it seemed like I was only going to write a proof that you can make a slow simulator swith cgen. The problem is that long immediates are available to a lot of different instruction formats by using an encoding that looks like 'core register 62'. Most of the instructions have two fields that can specify that. Trying to express this with separate formats is not feasible, a this would only quadruple the number of insn definition (double the number of formats but awkward decoding), but also cause trouble making the decoder generator comprehend where the boundaries between the different formats are. So I originally had the immediate fecth and pc increment in a piece of semantics. Now I've figured out I can go pbb by doing the pc increment based on instruction attributes in the pbb acse of mloop*.in.