From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14768 invoked by alias); 9 May 2003 16:17:52 -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 14753 invoked from network); 9 May 2003 16:17:51 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 9 May 2003 16:17:51 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id JAA28167; Fri, 9 May 2003 09:17:47 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma028132; Fri, 9 May 03 09:17:37 -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 h49GHea07553; Fri, 9 May 2003 09:17:40 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id JAA07892; Fri, 9 May 2003 09:17:40 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16059.54436.49779.706953@casey.transmeta.com> Date: Fri, 09 May 2003 16:17:00 -0000 To: Dave Brolley Cc: cgen@sources.redhat.com Subject: Re: [patch][rfa] Add ltu,leu,gtu,geu support for unsigned modes In-Reply-To: <3EBA9F61.3080403@redhat.com> References: <3EB80E66.70402@redhat.com> <16058.37129.53035.140393@casey.transmeta.com> <3EBA9F61.3080403@redhat.com> X-SW-Source: 2003-q2/txt/msg00039.txt.bz2 Dave Brolley writes: > That's why I was led to believe that this > support was appropriate. I'm not faulting you for thinking that. We need to reach a decision about Umodes and more rigidly enforce it. Mea culpa. I propose we set a direction of removing them entirely. One catch, to me anyway, is that I much prefer thinking of registers (esp. pc) as unsigned quantities. Thus an additional step might be to define SI as unsigned when it appears in C. At the semantic level it is neither signed nor unsigned, but C doesn't really have a way of understanding that, and that might cause confusion. Whether it'd be a more palatable confusion than having both SI and USI I dunno. > It may be excessive, but one could also argue that it's > more complete to support Umodes. Depends on how you look at things. To a cpu, a 32 bit register is a 32 bit register. Ditto for when the 32 bit quantity lives in memory. It's only in how it is subsequently used or interpreted that signedness might come into play. When signedness comes into play on the chip, it's explicitly specified in the operation, _not_ in the data. Ergo from this perspective Umodes don't belong in .cpu files. And I think this is the perspective we must use (when writing .cpu files anyway). > (if (lt (zext UDI op1) (zext UDI op2 ))(set op3 op1 )) > > works and it's hard to explain to the customer why ltu doesn't accept > umodes while lt does. Well, it's easy to explain. No claim is made that one's eyes won't roll. Is LTUDI LT concatenated with UDI or LTU concatenated with DI? > >@item UQI,UHI,USI,UDI > >Unsigned versions of QI,HI,SI,DI. > > > >These modes do not appear in semantic RTL. Instead, the RTL function > >specifies the signedness of its operands where necessary. > > [...] > > Perhaps this can help me convince the customer. I think if you explain the above reasoning that will also help.