| |
 | Posted by Johannes Pfau |  Permalink Reply |
|
Johannes Pfau 
| I recently tested the ARM port on an older ARM system (Marvell Kirkwood ARMv5TE) and found an issue which did not happen with the raspberry. This source file:
----------------------------------------------
import std.stdio;
void main()
{
ubyte[4] data = cast(ubyte[4])[1,1,1,1];
*cast(ushort *)&data[1] = 0;
writeln(data);
}
----------------------------------------------
(reduced from std.zip)
Produces this ASM:
----------------------------------------------
sub r3, fp, #8 ;r3 = &data
add r3, r3, #1 ;r3 = &data[1]
mov r2, #0 ;r2 = 0
strh r2, [r3] ;&data[1] = (ushort)0
----------------------------------------------
Output on raspberry:
----------------------------------------------
[1, 0, 0, 1]
----------------------------------------------
Output on kirkwood (same binary):
----------------------------------------------
[0, 0, 1, 1]
----------------------------------------------
Debugging shows that the 'strh' instruction corrupts the data. After some research I found this:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/BABDJCHA.html "a non halfword-aligned 16-bit save corrupts two bytes at [address] and [address–1]."
And this is exactly what's happening. It seems newer ARM cores are more forgiving with such stuff.
So my question is this: This is not the compilers fault, correct? If the user code were using array ops the unaligned save were detected, but if they use pointer arithmetic there's nothing the compiler could do?
|
