From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24871 invoked by alias); 29 Jan 2002 00:03:33 -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 24751 invoked from network); 29 Jan 2002 00:03:28 -0000 Received: from unknown (HELO miranda.axis.se) (193.13.178.2) by sources.redhat.com with SMTP; 29 Jan 2002 00:03:28 -0000 Received: from ignucius.axis.se (root@ignucius.axis.se [10.13.1.18]) by miranda.axis.se (8.12.1/8.12.1/Debian -2) with ESMTP id g0T03Qni017555; Tue, 29 Jan 2002 01:03:26 +0100 Received: (from hp@localhost) by ignucius.axis.se (8.9.3/8.9.3/Debian 8.9.3-21) id BAA12296; Tue, 29 Jan 2002 01:03:26 +0100 Date: Mon, 28 Jan 2002 16:03:00 -0000 Message-Id: <200201290003.BAA12296@ignucius.axis.se> From: Hans-Peter Nilsson To: cgen@sources.redhat.com Subject: Confusion: setup-semantics? PC not updated? Immediate operands? X-SW-Source: 2002-q1/txt/msg00018.txt.bz2 Hm, I can't get anything out from setup-semantics in a define-isa, like (example only): (define-isa (name cris) (base-insn-bitsize 16) (default-insn-word-bitsize 16) (liw-insns 1) (parallel-insns 1) (setup-semantics (error "Nothing happens")) ) This when generating that big GCC-specific C switch -switch.c, which seems generated from sim-cpu.scm. From what little scheme I understand (I'm blissfully naive), it seems only sid-cpu.scm, not sim-cpu.scm, supports setup-semantics. I'd use it for purposes similar to that of arm.cpu. Should it work? On a related matter, it seems pc isn't updated for non-CTI insns; it's value is that of the first insn in the chain. I need it as an operand in non-CTI insns. Oh right, there's a further related issue in the pipeline: how do I best specify 16-bit and 32-bit immediate operands? The immediate value is coded as indirect-pc-postincrement, "[pc+]", where pc is mapped as one of the 16 general registers. I'm currently hacking the update of pc in sim/cris/mloop.in in the case for "xextract-pbb" (based on fr30/mloop.in). I guess it's best to have a specific case for the "[pc+]" operand (leaving cases for other registers in a generally specified insn), but I need to at least tell CGEN to skip two or four bytes. I just can't see where to specify that. brgds, H-P