From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1387 invoked by alias); 2 Jun 2003 20:44:07 -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 1364 invoked from network); 2 Jun 2003 20:44:06 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 2 Jun 2003 20:44:06 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id NAA31366; Mon, 2 Jun 2003 13:44:01 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma031333; Mon, 2 Jun 03 13:43:47 -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 h52KhpB16529; Mon, 2 Jun 2003 13:43:51 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id NAA16782; Mon, 2 Jun 2003 13:43:51 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16091.46855.343504.902253@casey.transmeta.com> Date: Mon, 02 Jun 2003 20:44:00 -0000 To: Michael Meissner Cc: cgen@sources.redhat.com Subject: Re: Use of DI mode on 32-bit hosts In-Reply-To: <20030602192217.GA7082@tiktok.the-meissners.org> References: <20030602173232.GA5871@tiktok.the-meissners.org> <16091.36137.249864.565465@casey.transmeta.com> <20030602192217.GA7082@tiktok.the-meissners.org> X-SW-Source: 2003-q2/txt/msg00067.txt.bz2 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. 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. 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). 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" :-)]