From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5760 invoked by alias); 22 Jan 2002 11:57:52 -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 5726 invoked from network); 22 Jan 2002 11:57:51 -0000 Received: from unknown (HELO mailgate.risccores.com) (194.202.198.236) by sources.redhat.com with SMTP; 22 Jan 2002 11:57:51 -0000 Subject: supporting mixed 16/32-bit ISA's To: cgen@sources.redhat.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Peter.Targett@arccores.com Date: Tue, 22 Jan 2002 03:57:00 -0000 X-MIMETrack: Serialize by Router on Notes1/ARC(Release 5.0.8 |June 18, 2001) at 22/01/2002 11:59:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SW-Source: 2002-q1/txt/msg00008.txt.bz2 I've had a look through the CGEN mail archive and came across the mail below. I'm particularly interested in CGEN's ability to describe mixed 16/32 bit ISA's. We have a new ISA at ARC which has a truely intermixed 16/32 instruction set - basically, can I describe the ISA in CGEN? The 32-bit instructions (and long immediates that can form part of an instruction) are actually stored half-word endianized. Would this also be a problem? Thanks in advance for any advise, Peter. -- peter.targett@arccores.com --------------------------------------------------------------------- Broken decoder for 16/32 ISAs To: cgen at sources dot redhat dot com Subject: Broken decoder for 16/32 ISAs From: Ben Elliston Date: Thu, 31 May 2001 23:08:27 +1000 (EST) I have been debugging a problem in the generated decoder for the simulators. Here is the scenario, involving an ISA with a mix of 16 and 32 bit instructions (and lsb0? set to #f, so most significant bit is bit 0). The 16 bit instructions are laid out like so: +---------+---------+ | insn16 | | +---------+---------+ 0 15 And the 32 bit instructions are laid out like so: +-------------------+ | insn32 | +-------------------+ 0 31 The (-gen-decode-bits) function computes, amonst other things, the amount to shift a sequence of bits to the right, whereby they are then masked and examined by the decoder. For the architecture I've briefly described above, I believe the logic in utils-sim.scm is wrong: (shift (- (if lsb0? (- first bits -1) (- (+ start size) (+ first bit)) <---- pos))) The line indicated is used to compute the shift value when lsb0? is #f. Even for 16 bit instructions, the shift value needs to be at least 16 to get at the bits of insn16 (see above). The `size' variable seems to be passed in by callers, but it's unclear how this value is calculated or what it is meant to be in a variable length ISA. Shouldn't size really be the sizeof(insn) here? I'm a bit out of my depth in this part of cgen, but any suggestions would be much appreciated.