From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29977 invoked by alias); 3 Oct 2009 20:33:57 -0000 Received: (qmail 29968 invoked by uid 22791); 3 Oct 2009 20:33:57 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from c60.cesmail.net (HELO c60.cesmail.net) (216.154.195.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Oct 2009 20:33:53 +0000 Received: from unknown (HELO webmail1) ([192.168.1.181]) by c60.cesmail.net with ESMTP; 03 Oct 2009 16:33:52 -0400 Received: from 78.146.74.240 ([78.146.74.240]) by webmail.spamcop.net (Horde MIME library) with HTTP; Sat, 03 Oct 2009 16:39:55 -0400 Message-ID: <20091003163955.51so5zjyysow04k8-nzlynne@webmail.spamcop.net> Date: Sat, 03 Oct 2009 20:33:00 -0000 From: Joern Rennecke To: Doug Evans Cc: cgen@sourceware.org Subject: Re: ALIAS instructions are messed up? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) 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-q4/txt/msg00005.txt.bz2 > 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.] Currently, macro-instructions can't be used in all instances where it should be natural to use them. When you want to set a multi-ifield to a constant, you end up with the entire costant being added in in the bit position of each of constituent simple bitfields. By adding an ALIAS instruction by hand, you can at least work around the problem by setting only simple bitfields to constants.