XC16 optimizing "badly" access to a packed union/struct

[DarioG]

gotcha!
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...

[du00000001]

I didn't dig too deep, but might be that BFEXT is only applicable to word addresses (would make sense as start bit position and field length are defined within [0..15] resp. [1..16]). This restriction is not mentioned in the docs.
Seems this didn't yet transpire to the compiler writers.
In your specific case this could be easily worked around by clearing the LSBit of the address. As far as I can see, no further adjustments should be required.

[DarioG]

I imagined something like that, so thank you for your thoughts.

Not easy to workaround that in C, als because I think it will happen with all accesses to such members. But okay

(I will try selecting another 16bit CPU, just to check the "old way"!)

[du00000001]

" Not easy to workaround ... "

Switching off the optimization for this module ?

[DarioG]

Ah yep, I did it above! But... that's not nice...

[DarioG]

Indeed, without BFEXT things are much worse:

   2.750    0157A         238290                  MOV #0x3829, W0                    
   2.751    0157C         FB8010                  ZE [W0], W0                        
   2.752    0157E         DE0044                  LSR W0, #4, W0                    
   2.753    01580         EB8100                  SETM W2                            
   2.754    01582         EB8180                  SETM W3                            
   2.755    01584         DE83CF                  ASR W0, #15, W7                    
   2.756    01586         400002                  ADD W0, W2, W0                    
   2.757    01588         4B8083                  ADDC W7, W3, W1                    
   2.758    0158A         500FEE                  SUB W0, #0xE, [W15]                
   2.759    0158C         588FE0                  SUBB W1, #0x0, [W15]              
   2.760    0158E         3E0010                  BRA GTU, .L25                      
   2.761    01590         016000                  BRA W0      

(dsPIC33FJ256, optimization=1, XC16 1.41 latest)

[DarioG]

this is how "support" @ microchip shows available dsPIC33CH devices



Really, you wonder HTF those people work.

[du00000001]

Where's the problem ? This is the alpha-numerical sorting order taht's plaguing us since decades. Not restricted to Microchip - most parts of the world sort this way.
You can get accustomed to that

Or just type somewhat more than just the family's "christian name"

[DarioG]

well, the point is that those "1024" parts DO NOT EXIST! If you go to samples, you'll find none of such, just 64 and 128 parts.

On the other hand, in "support", ONLY those PHANTOM 1024 do fire out (as the scrollbar can somewhat show).

Try it yourself - I NEVER write nonsense (even if nobody believes me. but luckily comes coronavirus)

[DarioG]

and, just to be sure, I tried on microchip direct as well - no CH 1024 parts availablle...

[du00000001]

Ah - it's the support portal. Hardly a problem: if they consider dsPIC33CH1024 a valid derivative . . .

(The largest derivatives seem to be the ...CH512... ones - just like in the other recent dsPIC families.)
And - works like a charm - you can get samples e.g. of the DSPIC33CH512MP508-I/PT !

[DarioG]

yeah, but I don't have a PCB for that.

[DarioG]

of course:

[du00000001]

They prefer the easy way

Any way you could build them a small sample project around the snippet that produces the issue?
Hardly more than some basic initialization and the snippet called in main().

[DarioG]

sure I could. But I find this "disrespect" quite bad (also after all that happened on the forum).
They, like most humans, just deserve to die in their own idiocy!