OGAWA Hirofumi <[EMAIL PROTECTED]> writes:
> Daniel Phillips <[EMAIL PROTECTED]> writes:
>
>>> It may work actually, but e.g. arm, mips, superh, generetes alignment
>>> fault, then fault handler checks detail and fix it, or will calls
>>> BUG_ON() if source is kernel.
>>>
>>> There is no merit to generate alignment fault.
>>
>> I had the impression that gcc is supposed to generate code to access
>> the fields bytewise on architectures that generate alignment faults,
>> when the compiler can't prove statically that the fields are aligned.
>> I could be completely wrong about that...
>
> Um.. We will need to check recent gcc...
I've checked sh5-gcc-3.4 without optimize options. Sorry, it seems you
are right. At least, gcc of sh5 seems to care about that (and seems to
store a byte at a time). Um...
no packed version:
.loc 1 23 0
movi ((datalabel ileaf.0 >> 48) & 65535), r2
shori ((datalabel ileaf.0 >> 32) & 65535), r2
shori ((datalabel ileaf.0 >> 16) & 65535), r2
shori (datalabel ileaf.0 & 65535), r2
movi ((datalabel inum.1 >> 48) & 65535), r1
shori ((datalabel inum.1 >> 32) & 65535), r1
shori ((datalabel inum.1 >> 16) & 65535), r1
shori (datalabel inum.1 & 65535), r1
ld.q r1, 0, r1
st.q r2, 8, r1
packed version:
.loc 1 22 0
movi ((datalabel ileaf.0 >> 48) & 65535), r3
shori ((datalabel ileaf.0 >> 32) & 65535), r3
shori ((datalabel ileaf.0 >> 16) & 65535), r3
shori (datalabel ileaf.0 & 65535), r3
movi ((datalabel inum.1 >> 48) & 65535), r7
shori ((datalabel inum.1 >> 32) & 65535), r7
shori ((datalabel inum.1 >> 16) & 65535), r7
shori (datalabel inum.1 & 65535), r7
ld.q r7, 0, r1
andi r1, 255, r6
ld.ub r3, 4, r1
andi r1, 0, r1
add.l r1, r63, r2
add.l r6, r63, r1
or r2, r1, r1
st.b r3, 4, r1
ld.q r7, 0, r1
shlri r1, 8, r1
andi r1, 255, r6
ld.ub r3, 5, r1
andi r1, 0, r1
add.l r1, r63, r2
add.l r6, r63, r1
or r2, r1, r1
st.b r3, 5, r1
ld.q r7, 0, r1
shlri r1, 16, r1
andi r1, 255, r6
ld.ub r3, 6, r1
andi r1, 0, r1
add.l r1, r63, r2
add.l r6, r63, r1
or r2, r1, r1
st.b r3, 6, r1
ld.q r7, 0, r1
shlri r1, 24, r1
andi r1, 255, r6
ld.ub r3, 7, r1
andi r1, 0, r1
add.l r1, r63, r2
add.l r6, r63, r1
or r2, r1, r1
st.b r3, 7, r1
ld.q r7, 0, r1
shlri r1, 32, r1
andi r1, 255, r6
ld.ub r3, 8, r1
andi r1, 0, r1
add.l r1, r63, r2
add.l r6, r63, r1
or r2, r1, r1
st.b r3, 8, r1
ld.q r7, 0, r1
shlri r1, 40, r1
andi r1, 255, r6
ld.ub r3, 9, r1
andi r1, 0, r1
add.l r1, r63, r2
add.l r6, r63, r1
or r2, r1, r1
st.b r3, 9, r1
ld.q r7, 0, r1
shlri r1, 48, r1
andi r1, 255, r6
ld.ub r3, 10, r1
andi r1, 0, r1
add.l r1, r63, r2
add.l r6, r63, r1
or r2, r1, r1
st.b r3, 10, r1
ld.q r7, 0, r1
shlri r1, 56, r7
ld.ub r3, 11, r1
andi r1, 0, r1
add.l r1, r63, r2
add.l r7, r63, r1
or r2, r1, r1
st.b r3, 11, r1
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
_______________________________________________
Tux3 mailing list
[email protected]
http://tux3.org/cgi-bin/mailman/listinfo/tux3
