From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3117 invoked by alias); 2 Jun 2003 21:33:36 -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 2931 invoked from network); 2 Jun 2003 21:33:33 -0000 Received: from unknown (HELO tiktok.the-meissners.org) (206.15.128.82) by sources.redhat.com with SMTP; 2 Jun 2003 21:33:33 -0000 Received: from tiktok.the-meissners.org (localhost [127.0.0.1]) by tiktok.the-meissners.org (8.12.8/8.12.8) with ESMTP id h52LXUZT008668 for ; Mon, 2 Jun 2003 17:33:30 -0400 Received: (from meissner@localhost) by tiktok.the-meissners.org (8.12.8/8.12.8/Submit) id h52LXT63008666 for cgen@sources.redhat.com; Mon, 2 Jun 2003 17:33:29 -0400 Date: Mon, 02 Jun 2003 21:33:00 -0000 From: Michael Meissner To: cgen@sources.redhat.com Subject: Re: Use of DI mode on 32-bit hosts Message-ID: <20030602213329.GA8650@tiktok.the-meissners.org> Mail-Followup-To: Michael Meissner , cgen@sources.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16091.46855.343504.902253@casey.transmeta.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-q2/txt/msg00071.txt.bz2 On Mon, Jun 02, 2003 at 01:43:51PM -0700, Doug Evans wrote: > Michael Meissner writes: > > Basically I'm trying to build the gas tables at present, though the simulator > > will be next after I get gas/bfd/ld working. My machine is sort of like the > > IA-64 in that it is a 64-bit machine with a 64-bit address space, and the > > instructions are encoded as 3 instructions within a 128-bit field. I see the > > error when trying to use the ia64 machine as a reference port: > > > > --> /home/meissner/fsf-src/uberbaum/cgen --prefix=/home/meissner/tools/linux --target=ia64-linux > > --> make GUILE=~/install/guile-1.4.1/bin/guile opcodes > > rm -f tmp-opc.h tmp-itab.c > > rm -f tmp-asm.in tmp-dis.in tmp-ibld.h tmp-ibld.in > > /home/meissner/install/guile-1.4.1/bin/guile -s /home/meissner/fsf-src/uberbaum/cgen/cgen-opc.scm \ > > -s /home/meissner/fsf-src/uberbaum/cgen \ > > -v \ > > -f " opinst" \ > > -m all -a ia64 \ > > -O tmp-opc.h -P tmp-opc.c -Q tmp-opinst.c \ > > -B tmp-ibld.h -L tmp-ibld.in \ > > -A tmp-asm.in -D tmp-dis.in > > Skipping slib/sort, already loaded. > > Skipping slib/random, already loaded. > > cgen -s /home/meissner/fsf-src/uberbaum/cgen/cgen-opc.scm -s /home/meissner/fsf-src/uberbaum/cgen -v -f " opinst" -m all -a ia64 -O tmp-opc.h -P tmp-opc.c -Q tmp-opinst.c -B tmp-ibld.h -L tmp-ibld.in -A tmp-asm.in -D tmp-dis.in > > Setting option `opinst' to "". > > Loading cpu description /home/meissner/fsf-src/uberbaum/cgen/cpu/ia64.cpu > > Including file simplify.inc ... > > ERROR: /home/meissner/fsf-src/uberbaum/cgen/cpu/ia64.cpu:55: unknown entry type: > > (eval (begin (set! INT (mode:add! (quote INT) (mode:lookup (quote DI)))) (set! UINT (mode:add! (quote UINT) (mode:lookup (quote UDI)))) (set! WI (mode:add! (quote WI) (mode:lookup (quote DI)))) (set! UWI (mode:add! (quote UWI) (mode:lookup (quote UDI)))) (set! AI (mode:add! (quote AI) (mode:lookup (quote UDI)))) (set! IAI (mode:add! (quote IAI) (mode:lookup (quote UDI)))))) > > No backtrace available. > > make: *** [opcodes] Error 1 > > > > If I just do a (mode:lookup (quote DI)) it gives the same error message. > > Ah, that helps. > You are talking about target word size. > > This is unfinished business but I can easily finish it asap. > > The ia64.cpu port is trying to use `eval' to hack in a solution. > It shouldn't have to of course, and I'm guessing ia64.cpu either > used a private copy of cgen or hasn't been tried in awhile and > the reader has been tightened up to only accept what it should. > i.e. `(eval mumble)' is not a valid entry in a .cpu file and that's > what's causing the "unknown entry type" error. > If you replace (eval mumble) in ia64.cpu with #.(mumble) that > might achieve the desired result (suitably tweaked to get it to work > as I haven't tried it). Clearly it's still a hack though. Yeah, I suspect the ia64 port may have suffered bitrot. > The end of mode.scm had the beginnings of my solution but I ran > into difficulties of knowing when to call it. Specifically: > > (if #f > ; ???: Something like this would be nice if it was timed appropriately > ; redefine WI/UWI/AI/IAI for this target > (case (cpu-word-bitsize (current-cpu)) > ((32) (begin > (display "Recognized 32-bit cpu.\n"))) > ((64) (begin > (display "Recognized 64-bit cpu.\n") > (set! WI (mode:add! 'WI (mode:lookup 'DI))) > (set! UWI (mode:add! 'UWI (mode:lookup 'UDI))) > (set! AI (mode:add! 'AI (mode:lookup 'UDI))) > (set! IAI (mode:add! 'IAI (mode:lookup 'UDI))))) > (else (error "Unknown word-bitsize for WI/UWI/AI/IAI mode!")))) > > i.e. defer setting these until it's known what value to use. > (or, more precisely, set a default, and then change it as appropriate). > > Here's my proposed solution for WI,UWI,AI,IAI > (setting aside the orthogonal issue of what to do with U-modes): > > 1) Change mode.scm to no longer provide a default for WI,UWI,AI,IAI. > The value will be left as #f and the code will issue some sort of > error message if a proper value isn't set before it's used. > > 2) Provide one or more functions an app can call to set WI/UWI/AI/IAI. > - an opcodes like app might just want the biggest value (e.g. for > architectures that have both 32 and 64 bit variants use 64) > - a simulator like app would want just one value (and different copies > of the code would be generated for each value (e.g. separate 32 and > 64 bit versions) - or not, it's up to the app to decide. Something like c99's inttypes.h (which has types for give me an integer that is exactly 32-bit longs, and give me an integer that is at least 32-bits long, but could be larger depending on the local conditions). > 3) The application will be responsible for calling one of the functions > to set WI/UWI/AI/IAI as appropriate. > > 4) This doesn't address INT/UINT. Ideally it would remain 32 bits > (i.e. a portable int). Or maybe they should be slated to be removed. > I'll begin implementing this tonight if there are no objections. > Won't take more than a day. > > Is that acceptable? > > [I realize you don't want to trip over too many of these. > But these are issues that do need to be worked through > and if the response time is acceptable, "thank you for your support" :-)] It looks reasonable. Thanks by the way. I dunno what we should do about the SIMD vector types (ie, V2QI, V8DI, etc.). Most machines these days do have MMX/VIS/SSE/SSE2/etc. type instructions. The machine I'm targetting has a rather complete set of these instructions. -- Michael Meissner email: gnu@the-meissners.org http://www.the-meissners.org