Date: Mon, 4 Jan 1999 22:49:07 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Curt Sampson <cjs@cynic.net> Cc: sparc@FreeBSD.ORG Subject: Re: arch questions Message-ID: <Pine.BSF.4.05.9901042244550.37756-100000@bright.fx.genx.net> In-Reply-To: <Pine.NEB.4.02.9901041914480.12572-100000@epistolic.cynic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <cjs@cynic.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901042244550.37756-100000>