From owner-freebsd-sparc Mon Jan 4 19:45:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21098 for freebsd-sparc-outgoing; Mon, 4 Jan 1999 19:45:23 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21084 for ; Mon, 4 Jan 1999 19:45:21 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id WAA48870; Mon, 4 Jan 1999 22:49:07 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Mon, 4 Jan 1999 22:49:07 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Curt Sampson 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, Curt Sampson 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. long and pointer == 64bit? that makes sense. > > > 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? > When i was doing little 'demo' programs for the i386 i would use size override prfix to access 32bit registers from 'real' mode. This doesn't seem to be an option with gcc, either you get usparc, or sparc32, not some hybrid, and when you need to manipulate 64bit data, or multiply/divide/anything you do so in sparc32(v8) opcodes. Since sparc8 is compat with sparc9 you might as well use sparc9. -Alfred > 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