General Category > LisaList2

LisaEm 1.2.7-RC4 support bug reports

<< < (11/34) > >>

rayarachelian:
Another thing I've noticed is that inside the OS, I do see it using the CLR opcode. I remember recently reading some workshop docs that says that the assembler will internally replace CLR opcodes with MOVEQ 0, but I do see CLR used while I test, and as usual it does do the read before the write, which is inefficient.

So either this portion of code was created outside of that, or was form a much earlier assembler/code generator, or the pascal compiler doesn't do that.

And yeah, the PC here should be a02206ac as mentioned above


--- Code: --- read at 1/00f7d912(0011b512 phys).L=dce800f7
write at 1/00f7d912(0011b512 phys).L=00000000
core cache [-16+16]: 0x0022069c:6704 5340 4219 3200 e448 6700 000a 5340 4299 51c8 fffc 0801 0001 6702 4259 0801  | g$S.B92 dHg  *S.B9QH.|(! !g"BY(!
0/002206ac CLR.L      (A1)+

--- End code ---

D.Finni:

--- Quote from: rayarachelian on July 22, 2020, 11:13:52 am ---Another thing I've noticed is that inside the OS, I do see it using the CLR opcode. I remember recently reading some workshop docs that says that the assembler will internally replace CLR opcodes with MOVEQ 0, but I do see CLR used while I test, and as usual it does do the read before the write, which is inefficient.

--- End quote ---
By coincidence, I was reading those Workshop docs an hour ago, and they say the opposite: MOVEQ #0 is replaced by CLR. This optimization causes some problems when accessing hardware because CLR causes two memory accesses.

rayarachelian:

--- Quote from: D.Finni on July 22, 2020, 09:22:14 pm ---
--- End quote ---
By coincidence, I was reading those Workshop docs an hour ago, and they say the opposite: MOVEQ #0 is replaced by CLR. This optimization causes some problems when accessing hardware because CLR causes two memory accesses.
[/quote]

Hmm, I possibly misread/misremembered it then.

rayarachelian:
So it's worse than I though, this entire addressing mode is messed up, but now I've narrowed down its location.


--- Code: ---                lisa_ww_ram(0x20000,0x33b0); lisa_ww_ram(0x20002,0x0002); lisa_ww_ram(0x20004,0x1004); test_an_opcode_a(0x30000, 0x400000,d0,d1,k);
                lisa_ww_ram(0x20000,0x47F1); lisa_ww_ram(0x20002,0x1004); test_an_opcode_a(0x30000, 0x400000,d0,d1,k); // 47F1 1004   lea  4(A1,D1.W),A3
                lisa_ww_ram(0x20000,0x47F0); lisa_ww_ram(0x20002,0x1002); test_an_opcode_a(0x30000, 0x400000,d0,d1,k); // 47F0 1002   lea  2(A0,D1.W),A3
                lisa_ww_ram(0x20000,0x47F1); lisa_ww_ram(0x20002,0x0008); test_an_opcode_a(0x30000, 0x400000,d0,d1,k); // 47F1 0008   lea  8(A1,D0.W),A3
                lisa_ww_ram(0x20000,0x47F0); lisa_ww_ram(0x20002,0x000A); test_an_opcode_a(0x30000, 0x400000,d0,d1,k); // 47F0 000A   lea  10(A0,D0.W),A3

--- End code ---

All of these replace the D1 register with D0. It properly picks the A register as A0 or A1, but the D register is always D0.
I'd guess if I chose D7 or D2, it would show up as D0 anyway, and the disassembly is wrong too. In the 2nd code block below it should be D1 not D0


--- Code: ---
       regs D 0:00000004  1:000000cc  2:deadbeef  3:deadbeef  4:deadbeef  5:deadbeef  6:deadbeef  7:deadbeef  .S..z.. imsk:3
            A 0:00030000  1:00400000  2:deadbeef  3:0040000c  4:deadbeef  5:deadbeef  6:deadbeef  7:00040000  SP:00040000  PC:00020004  IR:47f1

 read at 1/00020012(000a0012 phys).W=00004efa
core cache [-16+16]: 0x0001fff0:ffff ffff ffff ffff ffff ffff ffff ffff 47f1 0008 1004 4e71 4e71 4e71 4e71 4e71  | ................Gq (0$NqNqNqNqNq
0/00020000 LEA.L      8(A1+D0.W),A3

ipc-opcode:47f1 used/set:00/00 wordlen:2 src:dst: 00000008 00000000 reg:0000
iib: mask/bits:f1f8/41f0 len:2 size:3 s/dtype:6/1 s/dbitpos:0 immvalue:00000009/0 cc:0
iib: priv:0 endblk:0 notzero:0 used:0 set:0, fn:0^^------------------------------------------------------------------------------------------------------------vv

--- End code ---

Actually, yeah, if I change the opcode to use D7, it still shows up as D0. That's the bug, it's not decoding the data register portion in this address mode properly.
It's dt_Aidx in the code.

rayarachelian:
bug has been fixed, linker works now, scrollbars and desktop menu are good.
Will take me a few days to rollback the pc24->pc32 changes and test if it breaks anything, the will push to github + push another RC, etc.

Navigation

[0] Message Index

[#] Next page

[*] Previous page