From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] sparc compiler bug From: Charles Forsyth Date: Mon, 10 Jan 2005 10:44:41 +0000 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-qrilxhpxucomttcnityimnzokc" Topicbox-Message-UUID: 2b83c5dc-eace-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-qrilxhpxucomttcnityimnzokc Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit only the linker knows the details, so any change would be made to kl. it's using the same approach for inherently 2-address FP instructions as it does for 3 address FP/INT instructions where only two operands are specified (set the third register to one of the others). i know the change needed but i'm curious whether they've added a trap check to the hardware that wasn't there before, or whether it's just something else complaining (but the hardware still doesn't). when i say i know the change needed, i'm assuming i'm `supposed' to set the field to 0 (even though that's also a valid register number). i can't find my sparc handbook today. --upas-qrilxhpxucomttcnityimnzokc Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by lavoro; Sun Jan 9 23:04:14 GMT 2005 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5A76863B1B for ; Sun, 9 Jan 2005 17:53:07 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 4C33B63A36 for <9fans@cse.psu.edu>; Sun, 9 Jan 2005 17:52:52 -0500 (EST) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01073-01-39 for <9fans@cse.psu.edu>; Sun, 9 Jan 2005 17:52:51 -0500 (EST) Received: from gau.lava.net (gau.lava.net [64.65.64.28]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 0A6B563A1D for <9fans@cse.psu.edu>; Sun, 9 Jan 2005 17:52:51 -0500 (EST) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by gau.lava.net (Postfix) with ESMTP id AA7311711E for <9fans@cse.psu.edu>; Sun, 9 Jan 2005 12:52:49 -1000 (HST) Date: Sun, 9 Jan 2005 12:52:49 -1000 (HST) From: Tim Newsham To: 9fans@cse.psu.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at cse.psu.edu Subject: [9fans] sparc compiler bug X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+forsyth=terzarima.net@cse.psu.edu Errors-To: 9fans-bounces+forsyth=terzarima.net@cse.psu.edu When generating conversion like "FsTOd" the compiler is generating invalid opcodes. The format for this and related instructions has an rs2 and an rd field but designates the rs1 field as reserved. The compiler/assembler/linker is generating: opcode=FsToD, rd=6, rs1=6, rs2=10 for the opcode "FSTOD F10, F6." This is an illegal use of a reserved field. I've tried to track this down but I'm still unfamiliar with the compiler suite. Tim N. --upas-qrilxhpxucomttcnityimnzokc--