I'll log a bug for this if need be, but I'd rather solve the problem myself (with some help). I'm in the middle of writing a routine (MD5 hashing for fun), and stumbled upon the following code generation problem in imcc.
In the attached code, I've got
$I10 = word & 0x000000ff
$I11 = word & 0x0000ff00
$I12 = word & 0x00ff0000
$I13 = word & 0xff000000and the resulting code becomes
band I17, I16, 0x000000ff
band I17, I16, 0x0000ff00
band I17, I16, 0x00ff0000
band I16, I16, 0xff000000Although $I10 to $I13 are all temps that are never used, I16 seems to become corrupted.
Can anyone shed some light on the area that I should be looking at; I guessing that it's to do with the code paths confusing things, or simply that the values are never used. Actually using $I13 seems to fix the problem (e.g. print $I13).
Some hints (such as deciphering parrot -d 8) would be appreciated,
Regards,
Nick Glencross
# Snip ...
.sub _md5_create_buffer
.param string str
.param Array buffer
.param int endian
.local int counter
.local int subcounter
.local int slow_counter
.local int word
$I0 = length str
$I1 = $I0 / 64
$I2 = $I0 % 64
$I3 = 64 * $I1
$I4 = $I3 / 4
buffer = $I4
word = 0
counter = 0
subcounter = 0
slow_counter = 0
md5_create_buffer_loop:
if counter >= $I3 goto md5_create_buffer_break
$I5 = counter + subcounter
$S0 = str[$I5]
$I4 = ord $S0
word = word << 8
word = word | $I4
subcounter = subcounter + 1
if subcounter != 4 goto md5_create_buffer_loop
if endian goto endian_ok
$I10 = word & 0x000000ff
$I11 = word & 0x0000ff00
$I12 = word & 0x00ff0000
$I13 = word & 0xff000000
# Some code snipped
endian_ok:
buffer[slow_counter] = word
counter = counter + 4
subcounter = 0
slow_counter = slow_counter + 1
goto md5_create_buffer_loop
md5_create_buffer_break:
.return 0
.end
# Snip ...
