Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!mcnc!rti!mozart!noe From: noe@unx.sas.com (Larry Noe) Newsgroups: comp.arch Subject: Re: RISC hard to program? (was: Moto's data predicts...) Message-ID: <1990Jul17.122831.12583@unx.sas.com> Date: 17 Jul 90 12:28:31 GMT References: <1990Jul13.071511.22250@Neon.Stanford.EDU> <37570@ucbvax.BERKELEY.EDU> Organization: Sas Institute Inc., Cary Lines: 25 In article <37570@ucbvax.BERKELEY.EDU> tve@sprite.berkeley.edu (Thorsten von Eicken) writes: >In article wsd@cs.brown.edu (Wm. Scott `Spot' Draves) writes: >>In article <1990Jul13.071511.22250@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: >>> SPARC requires fullword alignment for 32-bit operands and DOUBLEword >>> alignment (e.g. 8-bytes) for 64-bit operands, in memory. >>Are you sure? I think doubles can be loaded from 4 byte boundaries. >>Witness the following code, which runs fine on this SS1: >>[sample C code removed] > >This really depends on how doubles get loaded/stored. If the compiler >uses the load-double instruction, the data better be aligned on a >double (8 byte) boundary. If two load-word instructions are used, >word alignment is fine. I haven't figured out when compilers use >which instructions, but I have seen both. The compiler seems to generate ldd/std instructions for doubles that it knows to be aligned properly: automatics, statics and globals. Accessing a double through a pointer though generates a 2 instruction sequence. There is a new compiler switch in 4.1 though, '-dalign' that causes the compiler to always use ldd/std for doubles. -- Larry Noe (noe@unx.sas.com) "And I saw a sign on Easy Street, SAS Institute Inc. 'Be Prepared to Stop'" -- Don Henley