From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3956 invoked by alias); 15 May 2003 01:31:40 -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 3260 invoked from network); 15 May 2003 01:31:09 -0000 Received: from unknown (HELO tiktok.the-meissners.org) (130.105.39.3) by sources.redhat.com with SMTP; 15 May 2003 01:31:09 -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 h4F1UWIF001629 for ; Wed, 14 May 2003 21:30:32 -0400 Received: (from meissner@localhost) by tiktok.the-meissners.org (8.12.8/8.12.8/Submit) id h4F1UDeX001627 for cgen@sources.redhat.com; Wed, 14 May 2003 21:30:13 -0400 Date: Thu, 15 May 2003 01:31:00 -0000 From: Michael Meissner To: cgen@sources.redhat.com Subject: What is the state of cgen for architectures like the IA-64? Message-ID: <20030515013013.GA1220@tiktok.the-meissners.org> Mail-Followup-To: Michael Meissner , cgen@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-SW-Source: 2003-q2/txt/msg00044.txt.bz2 I'm doing a port for a new machine that has instruction encoding where instructions are logically of the format: +--+----------------------------------------------------+ |A |B | +--+----------------------------------------------------+ The instructions are then packed into a field of the form: +--+------------+---------------+---------------+ |C |B1 |B2 |B3 | +--+------------+---------------+---------------+ where C is an encoding for A1, A2, and A3. I believe this is similar to the format used by the IA-64 (but I only have a passing familarily with the IA-64). I tried building the ia64 opcodes, and it looks like it has bit-rotted (at least on my x86 Linux Red Hat 9 system, using a 1.4.1 guile instead of the 1.6 guile that is supplied with Red Hat 9): 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/cgen/src/cgen/cgen-opc.scm \ -s /home/meissner/fsf-src/cgen/src/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/cgen/src/cgen/cgen-opc.scm -s /home/meissner/fsf-src/cgen/src/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/cgen/src/cgen/cpu/ia64.cpu Including file simplify.inc ... ERROR: /home/meissner/fsf-src/cgen/src/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 So is cgen currently up to handling such an architecture without significant hacking? If the IA-64 is not fleshed out, is there another target in the public sources that would be more appropriate to look at? I suspect if I'm going to have to do significant surgery to cgen to get it to work, it will become less desirable to use it, and faster for me to do the port the old fashioned way. -- Michael Meissner email: gnu@the-meissners.org http://www.the-meissners.org