>>>>>> SIGBUS normally denotes unaligned access, but instruction in qustion >>>>>> pulls 16-bit value and effective address is 16-bit aligned... >>> I just tried a test .S file with >>> >>> ldda [%sp+0+16]%asi, %f0 >>> ldda [%sp+0+8]%asi, %f0 >>> ldda [%sp+0+4]%asi, %f0 >>> ldda [%sp+0+2]%asi, %f0 >>> >>> And +4 is the first one it SIGBUS'd on. So if the alignment in >>> sparcv9a-mont is increases to +8, it would also work on T1. >> Yes, but spacv9a-mont *relies* on +2, +4 and even +6. Offsets are used >> to pick 16-bit words constituting single [naturally aligned] 64-bit > > Hm. If I read the SPARC quick reference at > http://docs.sun.com/app/docs/doc/816-1681/sparcv9-15322?a=view right, > ldd(a) loads a floating point word rather than a 16-bit word, which > would explain why it declines non-8 aligned addresses.
With magic 0xD2 value in %asi register ldda []%asi reads 16-bit value and allows for 16-bit alignment. Quoting UltraSPARC User's Manual: "These ASIs allow 8- and 16-bit loads or stores to be performed to the floating-point registers. Eight-bit loads can be performed to arbitrary byte addresses. For sixteen bit loads, the least significant bit of the address must be zero, or a mem_not_aligned trap is taken." A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
