From owner-freebsd-sparc Mon Jan 4 19:16:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18354 for freebsd-sparc-outgoing; Mon, 4 Jan 1999 19:16:51 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from epistolic.cynic.net (epistolic.cynic.net [199.175.137.136]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18348 for ; Mon, 4 Jan 1999 19:16:49 -0800 (PST) (envelope-from cjs@cynic.net) Received: from localhost (localhost [[UNIX: localhost]]) by epistolic.cynic.net (8.9.1a/8.9.1) with SMTP id TAA12659; Mon, 4 Jan 1999 19:16:07 -0800 (PST) Date: Mon, 4 Jan 1999 19:16:07 -0800 (PST) From: Curt Sampson To: Alfred Perlstein cc: sparc@FreeBSD.ORG Subject: Re: arch questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 4 Jan 1999, Alfred Perlstein wrote: > a) the insturctions stay at 32bits wide, so we don't have much bloat to > worry about, and we don't incur much penalty for using larger ints. (if we > choose to use 64 bit ints) You'd probably want to stick with LP64, like the alpha, rather than go to ILP64. I don't really see any gain to ILP64. > b) using 64bit values/ABI is MUCH cheaper, in fact using old sparc32 > methods of accessing memory can seriously hurt performace as several > opcodes to access 64bit values in sparc32 code are depreciated and can > cause massive pipeline stalling and traps to the OS to emulate certain > VERY depreciated opcodes Surely the compiler can be told to avoid this stuff when generating 32-bit code? cjs -- Curt Sampson 604 801 5335 De gustibus, aut bene aut nihil. The most widely ported operating system in the world: http://www.netbsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message