From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20283 invoked by alias); 19 Jun 2002 18:05:32 -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 20198 invoked from network); 19 Jun 2002 18:05:29 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 19 Jun 2002 18:05:29 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id LAA10171; Wed, 19 Jun 2002 11:05:26 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma010144; Wed, 19 Jun 02 11:05:15 -0700 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id g5JI5Ij05465; Wed, 19 Jun 2002 11:05:18 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id LAA17618; Wed, 19 Jun 2002 11:05:18 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15632.51166.158258.170560@casey.transmeta.com> Date: Wed, 19 Jun 2002 11:05:00 -0000 To: Hans-Peter Nilsson Cc: cgen@sources.redhat.com Subject: [RFA:] Fix lsb? bug with insn fields beyond base insn size. In-Reply-To: <200206190111.DAA19613@ignucius.axis.se> References: <200206190111.DAA19613@ignucius.axis.se> X-SW-Source: 2002-q2/txt/msg00026.txt.bz2 Hans-Peter Nilsson writes: > This is a partial fix for what seems like a central problem: > bitfields are expressed as (start length) but whether "start" is > highest or lowest bit-number depends on "lsb0?". It looks like > that's an ungood design choice and causes several bugs, two > fixed below, I hope. (The "bitrange-overlap?" thingy looks > harmless though). If anyone would ask, I'd say convert all > bit-field numbering to be as for the lsb0? #f case: a bitfield > specified as (dnf f-op "" () 0 3) always starts at 0 and is 3 > bits long everywhere, regardless of lsb0?. One recognizes these issues going in. One problem to consider is whether the .cpu writer can enter the data using the numbering scheme found in the architecture manual, or whether s/he has to translate to cgen's scheme. Certainly .cpu derived machine generated documentation should match the architecture manual, but that can be done at document generation time. The issue then becomes one of maintenance. Are people willing to put up with having to continually do the translation for cpu's that happen to pick the "wrong" (1/2 :-) numbering scheme. And when they make mistakes will they also argue there's a bug? One alternative is to do the canonicalization at .cpu reading time, but that can also lead to confusion (causing people to revisit the issue again). I'm not fixed on the current scheme, but it shouldn't change without a full discussion and buy-in from people on the list. It'll take a day to study the patch.