From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11004 invoked by alias); 18 Jun 2009 17:27:14 -0000 Received: (qmail 10995 invoked by uid 22791); 18 Jun 2009 17:27:13 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX X-Spam-Check-By: sourceware.org Received: from sebabeach.org (HELO sebabeach.org) (64.165.110.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Jun 2009 17:27:04 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id 65AC16E3C4 for ; Thu, 18 Jun 2009 10:27:02 -0700 (PDT) Message-ID: <4A3A78E5.5030503@sebabeach.org> Date: Thu, 18 Jun 2009 17:27:00 -0000 From: Doug Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: cgen@sourceware.org Subject: ALIAS instructions are messed up? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2009-q2/txt/msg00046.txt.bz2 Blech. Handling of ALIAS instructions is messed up. From insn.scm:-insn-parse: (let ((ifield-assertion (if (not (null? ifield-assertion)) ifield-assertion #f)) (semantics (if (not (null? semantics)) semantics #f)) (format (-parse-insn-format (string-append errtxt " format") fmt)) (comment (parse-comment comment errtxt)) ; If there are no semantics, mark this as an alias. ; ??? Not sure this makes sense for multi-insns. (atlist-obj (if semantics atlist-obj (atlist-cons (bool-attr-make 'ALIAS #t) atlist-obj))) (syntax (parse-syntax syntax errtxt)) (timing (parse-insn-timing errtxt timing)) ) If this were a `let*', then things would be a bit clearer, but not completely. [the checking for alias insns won't work if it's expecting the previous assignment of semantics to change () to #f] This comes up because generating the html doc for xc16x.cpu crashes because its "nop" instruction has () for semantics. I can't remember if there's any usefulness to ALIAS insns that isn't provided by macro-insns. Can anyone? I don't have too strong a preference on what to do here (though I reserve the right to change my mind :-)). Since, e.g., simulators rightly ignore ALIAS insns it seems like we want to flag insns in .cpu files with missing/empty semantics as an error and not silently convert them to aliases. Nop insns would be required to specify (nop) for their semantics. It'd be interesting to see if making this change causes any changes to the generated code. Whether to disallow alias insns entirely is a separate question. Dunno. [We could still keep it for macro-insns. And I realize there are a few ports that currently use it, or at least specify it.]