From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4753 invoked by alias); 21 Jun 2009 23:07:03 -0000 Received: (qmail 4745 invoked by uid 22791); 21 Jun 2009 23:07:02 -0000 X-SWARE-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BAYES_40,DNS_FROM_RFC_BOGUSMX,J_CHICKENPOX_22,J_CHICKENPOX_23,J_CHICKENPOX_43 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; Sun, 21 Jun 2009 23:06:57 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id 436F06E3C4; Sun, 21 Jun 2009 16:06:55 -0700 (PDT) Message-ID: <4A3EBD0E.5080109@sebabeach.org> Date: Sun, 21 Jun 2009 23:07:00 -0000 From: Doug Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Dave Korn CC: cgen@sources.redhat.com Subject: Re: unable to find precise mode to match cpu word-bitsize 24 References: <4A3E86AA.2080002@gmail.com> In-Reply-To: <4A3E86AA.2080002@gmail.com> 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/msg00057.txt.bz2 Dave Korn wrote: > Hello CGEN list, > > I'm attempting to develop a model of a CPU that has a natural 24-bit > wordsize: 24-bit registers, 24-bit ALU, 24-bit data bus... 24-bit everything, > and no subword or unaligned accesses - in fact, you could really call them > 24-bit bytes, as it's the minimum addressable unit. > > A naive attempt to just write > > (define-cpu > [ . . . ] > (word-bitsize 24) > [ . . . ] > ) > > fails with the error message from the title of this post. I've crudely hacked > in a couple of three-quarter int modes like this: > > Index: mode.scm > =================================================================== > RCS file: /cvs/src/src/cgen/mode.scm,v > retrieving revision 1.4 > diff -p -u -r1.4 mode.scm > --- mode.scm 16 Jul 2003 05:35:47 -0000 1.4 > +++ mode.scm 21 Jun 2009 18:45:00 -0000 > @@ -499,6 +499,7 @@ Define a mode, all arguments specified. > > (dfm 'QI "8 bit byte" '() 'INT 8 1 "int" "'x'" #f #f #f) > (dfm 'HI "16 bit int" '() 'INT 16 2 "int" "'x'" #f #f #f) > + (dfm 'TQI "24 bit int" '() 'INT 24 3 "int" "'x'" #f #f #f) > (dfm 'SI "32 bit int" '() 'INT 32 4 "int" "'x'" #f #f #f) > (dfm 'DI "64 bit int" '(FN-SUPPORT) 'INT 64 8 "" "'D'" #f #f #f) > > @@ -506,6 +507,8 @@ Define a mode, all arguments specified. > 8 1 "unsigned int" "'x'" (mode:lookup 'QI) #f #f) > (dfm 'UHI "16 bit unsigned int" '() 'UINT > 16 2 "unsigned int" "'x'" (mode:lookup 'HI) #f #f) > + (dfm 'UTQI "24 bit unsigned int" '() 'UINT > + 24 3 "unsigned int" "'x'" (mode:lookup 'TQI) #f #f) > (dfm 'USI "32 bit unsigned int" '() 'UINT > 32 4 "unsigned int" "'x'" (mode:lookup 'SI) #f #f) > (dfm 'UDI "64 bit unsigned int" '(FN-SUPPORT) 'UINT > > > just so that I can get on with writing my i-fields, but will it work? If I > want my (simulated) pc to increment in steps of 1, not 3, should I define the > number of bytes to 1 instead of 3? Or would I be best off redefining QI mode > altogether? Sorry if this is a n00b question, but a bit of googling and > grepping didn't show up anyone trying this before. > > This is new ground so we can decide how we want things to look, and then make it work. I think(!) that we don't want to redefine QI. For clarity's sake, the T in TQI is for "Three", right? [3 * 8 = 24] I've been thinking that while QI,HI,SI,DI are clear, any other similarly named modes might become problematic over time. An alternative is I24 of course, but if one goes that route one needs to resolve what to do about QI,etc. [They *could* become aliases of I8, etc. and perhaps eventually be removed entirely, at least from the application independent core. Anything related to gcc may certainly want to use them.] This route has the benefit of solving this problem for future weird architectures. [And just because we add I24 doesn't mean we'd have to immediately add all the others, e.g. I23, etc.] Also, since it's related, I've been thinking of removing UQI, UHI, etc. They were a useful internal implementation detail at one point, but I think they've become more of a problem than a help. [But we needn't block this discussion on what happens with that.] I'd be curious to hear what others think.