simulator quirks and assembly problems

[janni]

Hoping that the following will be taken into account while preparing new compiler version, here's a list of software simulator quirks that cause most problems:

- DC (digital carry) is not emulated in STATUS register which precludes use of some effective BCD algorithms,
- any change to STKPTR causes simulator break,
- simulator freezes if any of STKPTR bits is set changing it,
- BRA is simulated to take 1 instead of 2 Tcy (enhanced series only),
- enhanced series ADDFSR instruction is simulated as only positive value could be added (0..63, instead of -32..31).

Some of us use assembly (especially in time-critical applications) and are hindered by the following

- GOTOs are treated by linker like CALLs, which means that unfounded 'lack of stack space' error is claimed if GOTOs lead to (harmless) function loops,
- not only use of GOTO and CALL instructions is severely limited, in enhanced series one cannot even call routines enclosed within single assembly block,
- semicolon does not act as real comment in asm block (depending on compiler, apostrophe or parenthesis, or some keywords, like 'end' are interpreted by compiler and Code Explorer),
- empty 'badram' declaration in *.mcl file causes compiler to assume that 0 is bad RAM location which causes problems with use of R0 register in PIC18s.

[filip]

Hi,

Thank you reporting these quirks, we will check them and fix them as soon as possible.

Regards,
Filip.

[rajkovic]

Could you please post a part of code which demonstrate this behaviour, (this is for P16ENH family) ?

- any change to STKPTR causes simulator break,
- simulator freezes if any of STKPTR bits is set changing it,

[janni]

Could you please post a part of code which demonstrate this behaviour, (this is for P16ENH family) ?

I spotted it several compiler versions back while correcting errors in setjmp/longjmp and writing bootloaders for PIC18 processors.

If you run the compiler setjmp example, you'll see simulator stopping execution of longjmp (while stepping over it) after assembly instruction moving POSTINC0 to STKPTR. That's not a game-stopper, just annoying, but may be quite confusing for some users.

Modifying STKPTR causes other strange effects, like skipping following instruction or freezing the simulator. For example (tested for PIC18F4620)

Code: Select all

#include "built_in.h"

unsigned long ER_exc;

void trySTKPTR1() {
 asm nop;           // STKPTR=3
}

void trySTKPTR() {
  trySTKPTR1();     // STKPTR=2
  STKPTR++;         // program jumps
  asm {
   nop
   nop              // ...here, STKPTR=3
  }
  STKPTR--;         // STKPTR=2
  asm {
   bsf STKPTR,0     // simulator freezes when clear bit is set
   bcf STKPTR,1     // ...but not when set bit is cleared
   nop
  }

  PCLATU=Lo(ER_exc);// works fine
  PCLATH=Hi(ER_exc);
  R0=Higher(ER_exc);
  asm {
        movf        R0,W
        movwf       PCL
  }
}

void dummy() {
  Lo(ER_exc)=TOSU;                 // store return address and STKPTR
  Hi(ER_exc)=TOSH;
  Higher(ER_exc)=TOSL;
  Highest(ER_exc)=STKPTR;
  trySTKPTR();
}

void main() {
  dummy();
  asm nop;
}

ADDED: Just to make things clear - changes to STKPTR should cause no effect till an operation involving the stack happens (like one of calls, returns, or if Top Of Stack is manipulated).