From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14024 invoked by alias); 22 Jun 2009 17:05:35 -0000 Received: (qmail 13874 invoked by uid 22791); 22 Jun 2009 17:05:33 -0000 X-SWARE-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX,J_CHICKENPOX_22,J_CHICKENPOX_23 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; Mon, 22 Jun 2009 17:05:27 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id 1FC7D6E3C4; Mon, 22 Jun 2009 10:05:26 -0700 (PDT) Message-ID: <4A3FB9D5.9070103@sebabeach.org> Date: Mon, 22 Jun 2009 17:05: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> <4A3EBD0E.5080109@sebabeach.org> <4A3ECDBB.1000806@gmail.com> In-Reply-To: <4A3ECDBB.1000806@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/msg00061.txt.bz2 Dave Korn wrote: > Doug Evans wrote: > > >> This is new ground so we can decide how we want things to look, and then >> make it work. >> > > Well, what I'd particularly like in this case would be for my pc to > increment by one for each 24-bit insn, rather than have the model pretend to > be an 8-bit CISC machine processing all 3-byte instructions, if you see what I > mean. > Righto. That should be doable regardless. > >> I think(!) that we don't want to redefine QI. >> > > Well, if you do a GCC port with #define BITS_PER_UNIT 24, don't you get a > 24-bit QImode? I don't know how closely the XXmodes in cgen are meant to > match the semantics of GCC's modes, or whether it's just a friendly and > familiar naming scheme to adopt. > Good point. It's not clear just how closely to follow gcc, but I have tried not to diverge *too* much. [*Certainly* there are debatable instances.] OTOH, not everything in gcc is chocolatey goodness or applicable. And gcc is just one app. A simulator, for example, needs to know both the host and the target wordiness. Having QI be one thing on the host and something else on the target may be an issue (at least to the extent that it's one more thing whose meaning is context dependent). > >> For clarity's sake, the T in TQI is for "Three", right? [3 * 8 = 24] >> > > Yep. I guess I could also call it PSImode by analogy to GCC. > > >> 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.] >> > > Well, the most flexible option I think would be to implement the equivalent > of BITS_PER_UNIT and have the QI/HI/SI/DI modes adjust to match, maybe. I'm > really new to this and don't fully understand how modes are used in cgen yet, > but if it's ever a long-term goal to be able to cgen parts of the GCC backend, > it would be handy to mirror the same storage-layout abilities. > > Modes serve two purposes: specify how big something is in bits, and specify interpretation (e.g. int vs float). Things are muddied a bit, e.g. the operation kind (e.g. div vs udiv) specifies signedness but the mode specifies int vs float. Blech. Going forward maybe the thing to do is remove meaning from the mode (e.g. just specify number of bits), have interpretation provided by the operation, and if an app wants to provide its own names for certain modes (e.g. gcc's QImode) then leave it to the app.