From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21228 invoked by alias); 13 Feb 2007 15:37:44 -0000 Received: (qmail 21220 invoked by uid 22791); 13 Feb 2007 15:37:43 -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 15:37:31 +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 l1DFbHbG016485; Tue, 13 Feb 2007 15:37:17 GMT Received: (from joernr@localhost) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11/Submit) id l1DFbHcr016483; Tue, 13 Feb 2007 15:37:17 GMT Date: Tue, 13 Feb 2007 15:37:00 -0000 From: Joern Rennecke To: cgen@sources.redhat.com Subject: delayed branches and zero overhead loops Message-ID: <20070213153717.GA12710@elsdt-razorfish.arc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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/msg00037.txt.bz2 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, and found that it might decode one more instruction than max_insns, when the pbb ends with a delay slot insn. Is that a bug, or legitimate? For zero overhead loop processing, I think the pbb handling makes most sense when a pseudo instruction is inserted at the end of a loop, and when the loop end is changed, any afected pbb is invalidated. Like for delay slots, this pseudo instruction will need and extra decoded insn slot, so again it is important to know if it is allowed to use one extra slot. A further problem is that I don't want to have a nonsense encoding for the pseudo insn which could be triggered by invalid code, and/or cause decoder conflicts. Hence, there should be a way to define instruction semantics without an instruction encoding. What do you think would the bets way to express this? No format field? Treating an empty format field in a special way? Adding a magic attribute that causes the format field (or its absence) to be ignored?