From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31826 invoked by alias); 2 Jun 2003 22:04:49 -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 31790 invoked from network); 2 Jun 2003 22:04:48 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 2 Jun 2003 22:04:48 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id PAA04539; Mon, 2 Jun 2003 15:04:41 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma004502; Mon, 2 Jun 03 15:04:17 -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 h52M4MB23280; Mon, 2 Jun 2003 15:04:22 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id PAA17173; Mon, 2 Jun 2003 15:04:21 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16091.51685.885875.214781@casey.transmeta.com> Date: Mon, 02 Jun 2003 22:04:00 -0000 To: "Frank Ch. Eigler" Cc: cgen-mail@the-meissners.org, cgen@sources.redhat.com Subject: Re: Use of DI mode on 32-bit hosts In-Reply-To: <20030602213226.GB22856@redhat.com> References: <20030602173232.GA5871@tiktok.the-meissners.org> <16091.36137.249864.565465@casey.transmeta.com> <20030602192217.GA7082@tiktok.the-meissners.org> <16091.46855.343504.902253@casey.transmeta.com> <20030602204936.GA22856@redhat.com> <16091.49399.661309.108837@casey.transmeta.com> <20030602213226.GB22856@redhat.com> X-SW-Source: 2003-q2/txt/msg00072.txt.bz2 Frank Ch. Eigler writes: > I guess I don't see the abstraction and simplicity this > indirection is to provide. Do you have an example? - I'd rather have one version of "add" for sparc 32/64 - I'd rather write 'IAI in the .scm sources when refering to 'pc than doing something else [for example] > > INT/UINT are treated separately. They're for host values > > where one doesn't care about target sizes. > > In what circumstances do you consider it reasonable for cgen > model files to deal with host data types/sizes? Don't say "deal with host data types/sizes". That'll trigger arguments that go off on tangents. Each host has lots of data types/sizes. What I meant was integers not tied to particular widths, and for pragmatic sake one can assume the application will have available at least a 32 bit integral type to use. Sometimes the code will need a mode but imposing a specific width muddies the waters. If one wanted to write some rtl that looped over something, picking one of QI/HI/SI/DI may be less appealing than "just give me a big enough int". How many in C-land write "for (unsigned i = 0; mumble; mumble) vs "for (uint32_t i = 0; mumble; mumble)"? [ And actually I was incomplete. INT/UINT are also used for varying width values, whereas SI/DI have explicit widths. So actually, I should have two separate forms of INT/UINT, but the distinction has yet to be needed. >From doc/rtl.texi: @example @code{(immediate mode)} @code{(immediate (mode bits))} @end example The second form is for values for which a mode of that size doesn't exist. @samp{mode} for the second form must be one of @code{INT} or @code{UINT}. Since these two modes don't have an implicit size, they cannot be used for the first form. ??? There's no real reason why a mode like SI can't be used for odd-sized immediate values. The @samp{bits} field indicates the size and the @samp{mode} field indicates the mode in which the value will be used, as well as its signedness. This would allow removing INT/UINT for this purpose. On the other hand, a non-width specific mode allows applications to choose one (a simulator might prefer to store immediates in an `int' rather than, say, char if the specified mode was @code{QI}). [and I should rephrase that to say that imposing one width with SI on a value (e.g. immediate) of a different width is confusing] ]