On Jan 9, 2013, at 7:27 PM, Mark Cave-Ayland wrote:
(this is what I get with the patch I just posted applied):
0 > here 10 0 fill ok 0 > here 4 44332211 filll ok 0 > here 8 dump fff503c0 44 33 22 11 00 00 00 00 00 00 00 00 00 00 00 00 D3".............
Same as Open Firmware.
0 > here 5 44332211 filll ok 0 > here 8 dump fff503c0 44 33 22 11 44 00 00 00 00 00 00 00 00 00 00 00 D3".D...........
This output in incorrect. This is what Open Firmware outputs: ff94d75c: 44 33 22 11 44 33 22 11
0 > here 6 44332211 filll ok 0 > here 8 dump fff503c0 44 33 22 11 44 33 00 00 00 00 00 00 00 00 00 00 D3".D3..........
This output is also incorrect. This is what Open Firmware outputs: ff94d75c: 44 33 22 11 44 33 22 11
0 > here 7 44332211 filll ok 0 > here 8 dump fff503c0 44 33 22 11 44 33 22 00 00 00 00 00 00 00 00 00 D3".D3".........
This output is incorrect. This is what Open Firmware outputs: ff94d75c: 44 33 22 11 44 33 22 11
0 > here 8 44332211 filll ok 0 > here 8 dump fff503c0 44 33 22 11 44 33 22 11 00 00 00 00 00 00 00 00 D3".D3"........
This output is correct.
Segher is wrong.
On 10/01/13 18:25, Programmingkid wrote:
On Jan 9, 2013, at 7:27 PM, Mark Cave-Ayland wrote:
(this is what I get with the patch I just posted applied):
0> here 10 0 fill ok 0> here 4 44332211 filll ok 0> here 8 dump fff503c0 44 33 22 11 00 00 00 00 00 00 00 00 00 00 00 00 D3".............
Same as Open Firmware.
0> here 5 44332211 filll ok 0> here 8 dump fff503c0 44 33 22 11 44 00 00 00 00 00 00 00 00 00 00 00 D3".D...........
This output in incorrect. This is what Open Firmware outputs: ff94d75c: 44 33 22 11 44 33 22 11
0> here 6 44332211 filll ok 0> here 8 dump fff503c0 44 33 22 11 44 33 00 00 00 00 00 00 00 00 00 00 D3".D3..........
This output is also incorrect. This is what Open Firmware outputs: ff94d75c: 44 33 22 11 44 33 22 11
0> here 7 44332211 filll ok 0> here 8 dump fff503c0 44 33 22 11 44 33 22 00 00 00 00 00 00 00 00 00 D3".D3".........
This output is incorrect. This is what Open Firmware outputs: ff94d75c: 44 33 22 11 44 33 22 11
0> here 8 44332211 filll ok 0> here 8 dump fff503c0 44 33 22 11 44 33 22 11 00 00 00 00 00 00 00 00 D3".D3"........
Hmmm well that looks as if it just rounds up to the next 4-byte word, which is like the last patch but without the extra byte handling on the end. Segher - can you confirm this on your hardware?
ATB,
Mark.
Hmmm well that looks as if it just rounds up to the next 4-byte word, which is like the last patch but without the extra byte handling on the end. Segher - can you confirm this on your hardware?
I'm too lazy to power up some, sorry. But how about looking at the code, instead?
code filll mr r4,r20 lwz r3,0(r31) lwz r5,4(r31) mr. r3,r3 lwzu r20,8(r31) addi r31,r31,4 ble- 0x2c addic. r3,r3,-4 stw r4,0(r5) addi r5,r5,4 bc+ 20,lt,0x18 blr end-code
Segher
(That weirdo "bc" at the end is just an unconditional jump, coded very strangely).
0 > here 5 44332211 filll ok 0 > here 8 dump fff503c0 44 33 22 11 44 00 00 00 00 00 00 00 00 00 00 00 D3".D...........
This output in incorrect. This is what Open Firmware outputs: ff94d75c: 44 33 22 11 44 33 22 11
That is debatable; you could say that Apple's implementation is buggy, instead. You can also say that the API is badly designed, this problem is wholly avoidable.
0 > here 8 44332211 filll ok 0 > here 8 dump fff503c0 44 33 22 11 44 33 22 11 00 00 00 00 00 00 00 00 D3".D3"........
This output is correct.
Segher is wrong.
No, I'm not. I *said* that Apple OF writes too many bytes.
I don't think that emulating this behaviour is useful. I don't think that Mark's do-the-tail-by-bytes is useful either. As I said, bad API; we should just consider any length not a multiple of four as resulting in undefined behaviour.
Segher
-
Mark Cave-Ayland -
Programmingkid -
Segher Boessenkool