Post by DarioG on Jan 20, 2020 14:57:35 GMT
gotcha!
Porting ARM emulator from XC32/PIC32 to XC16/dsPIC, this struct/union which manages the full 32bits opcode
causes a memory access error here
It turns out that, at Optimizations=0, the code is okay:
while, with Optimizations=1
Now, I'm not a big expert of PIC24 assembler, and even less about the new stuff introduced by CH series, but I tend to believe that BFEXT instructions is misused (or bugged).
I would love to report this to Microchip, if only they had not shown being a bunch of careless misattituted...
Porting ARM emulator from XC32/PIC32 to XC16/dsPIC, this struct/union which manages the full 32bits opcode
struct __attribute__((__packed__)) ARM_OPCODE {
union __attribute__((__packed__)) {
struct __attribute__((__packed__)) {
unsigned int Rm: 4;
unsigned int shiftType: 1;
unsigned int shift: 2;
unsigned int shiftAmount: 5;
unsigned int Rd: 4;
unsigned int Rn: 4;
unsigned int S: 1;
unsigned int opcode: 4;
unsigned int optype: 3; // volevo metterli al di fuori di queste struct, ma poi "sfora" in un byte extra... a me pare un bug ma c'è chi dice che è giusto così, sono "oggetti separati SEMPRE" https://stackoverflow.com/questions/29428710/forcing-union-alignment-inside-struct
unsigned int cond: 4;
} type0;
(see other post for full code)causes a memory access error here
switch(Pipe.opcode.type0.cond) {
It turns out that, at Optimizations=0, the code is okay:
3.126 0186A 240290 MOV #0x4029, W0
3.127 0186C 784010 MOV.B [W0], W0
3.128 0186E 0A8074 BFEXT #0x4, #0x4, W0, W0
while, with Optimizations=1
2.825 01610 240290 MOV #0x4029, W0
2.826 01612 0A8274 BFEXT #0x4, #0x4, [W0], W2
2.827 01614 000010 NOP
Now, I'm not a big expert of PIC24 assembler, and even less about the new stuff introduced by CH series, but I tend to believe that BFEXT instructions is misused (or bugged).
I would love to report this to Microchip, if only they had not shown being a bunch of careless misattituted...