I'm pretty sure odd address access is perfectly acceptable with a 68020,
but could be wrong.
On 25/01/2013 10:47, Norman Dunbar wrote:
Morning all,
I'm doing a bit more work on the next exciting episode of QL Today's
LibGen utility. I have spotted a huge pair of bugs in my code, viz:
li_libfile equ $03
...
li_unav move.l #$11111111,ws_litem+li_libfile(a1)
bra.s li_rdrw
...
li_avail move.l #$01011101,ws_litem+li_libfile(a1)
li_rdrw moveq #-1,d3
jmp wm_ldraw(a2)
The idea was to set 4 consecutive loose item status bytes to
unavailable (#wsi_mkun) in the first case, and to set three of them to
available (#wsi_mkav) and one to unavailable (#wsi_mkun) in the second
case.
The code above is a huge problem because li_libfile is odd, A1 is even
as is ws_litem at $40. I would expect an address exception at the very
least.
Running the code under QMON2 shows that I'm attempting to store a long
word at $43(a1) where a1 is $4ABBA6. That works out at $4ABBE9 which
is most definitely odd.
In QPC, version 3.33, the above works without any exceptions. PRINT
PROCESSOR gives 20, I must assume that either a 68020 doesn't barf at
a long word access to an odd address or something is not working
correctly any more!
I've checked and rechecked my paper and pdf copies of the Motorola
processor manual, and there is no mention that you can do a long move
to an odd address.
I'm not running any "monitor" code that would intercept the address
exceptions and quietly swallow it.
I have stepped through the code for both, and it works, the MOVE.L is
carried out, after executing the code at li_avail, I can see the
following results at $43(a1) in QMON2:
QMON> d $43(a1) 4
4ABBE9 0101 0101 004E FF6F .....NV.
Is it any wonder I'm confused?
What am I missing?
Cheers,
Norm.
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
