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 & 0xff000000
and the resulting code becomes
band I17, I16, 0x000000ff band I17, I16, 0x0000ff00 band I17, I16, 0x00ff0000 band I16, I16, 0xff000000
Although $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 ...