From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9963 invoked by alias); 13 May 2004 19:24:13 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 9954 invoked from network); 13 May 2004 19:24:12 -0000 Received: from unknown (HELO mms2.broadcom.com) (63.70.210.59) by sourceware.org with SMTP; 13 May 2004 19:24:12 -0000 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 13 May 2004 12:23:20 -0700 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from mail-cbga-1.eu.broadcom.com (mail-cbga-1.eu.broadcom.com [10.177.128.40]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA26820; Thu, 13 May 2004 12:22:45 -0700 (PDT) Received: from broadcom.com (dhcpe-cbga-102 [10.177.64.102]) by mail-cbga-1.eu.broadcom.com (8.12.9/8.8.8/MS01) with ESMTP id i4DJNHiG001358; Thu, 13 May 2004 20:23:17 +0100 (BST) Message-ID: <40A3CB25.9090305@broadcom.com> Date: Thu, 13 May 2004 19:24:00 -0000 From: "Adrian Ashley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: cgen@sources.redhat.com cc: "Doug Evans" Subject: Re: tabling constant-field-beyond-base patch References: <20030806175257.64167B53E@mail.sebabeach.org> In-Reply-To: <20030806175257.64167B53E@mail.sebabeach.org> X-WSS-ID: 6CBD14AD1JW8238723-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-q2/txt/msg00005.txt.bz2 Way back in Aug-2003, Doug Evans wrote: > Finishing up the remaining bits of this patch are proving difficult. > [N.B. The issues aren't of a technical nature.] So I'm tabling the > current state of the patch here. > > I hope to have the difficulties resolved RSN. Sigh. I'm working on a port to a (little-endian) machine which has some 64-bit instructions which are extended versions of 32-bit ones - i.e. ambiguous in the lower 32-bits but distinguishable by looking at some of the upper 32-bits. CGEN currently goes bong in -build-decode-table-entry when it detects the ambiguity. In my search through the archives it looks like this work might be a good starting point. Other postings referred to the possibility of making CGEN_INSN_INT a long long and removing all the assumptions that it is actually 32 bits - though replacing them with only slightly less rigid assumptions that it's "32 or 64". Has this problem been solved already? If not, can the sages offer advice as to the most fruitful way to proceed? I'm currently trying the "CGEN_INSN_INT is long long" approach, in the absence of fully understanding the bigger picture. Thanks, A Ashley