Skip to main content
Visitor II
September 8, 2006
Question

Cosmic compiler & BTJF problem

  • September 8, 2006
  • 4 replies
  • 914 views
Posted on September 08, 2006 at 18:12

Cosmic compiler & BTJF problem

    This topic has been closed for replies.

    4 replies

    bramAuthor
    Visitor II
    September 8, 2006
    Posted on September 08, 2006 at 08:36

    Hi,

    I'm having problems writing some basic inline assembly. Or better put, the compiler seems to have problems with my assembly code.

    The code concerned is:

    _asm(''BitTest: BTJF 0x34, #7, BitTest'');

    When I compile the file containing the above in ''debug'' mode, there is no problem. But when I switch to ''release'' mode, the problem arises.

    In both cases, I use the Cosmic toolchain.

    The compiler start complaining, giving me an error message like:

    cost7: bad branch label 0x34, #7, BitTest

    Any ideas on why the compiler generates this message? Ofcourse the same could be achieved using a simple while loop, but doing it this way seems to be somewhat faster.

    Hope you can help!

    Visitor II
    September 8, 2006
    Posted on September 08, 2006 at 12:17

    Hi,

    note that you can achieve exactly the same in C using the sequence

    Code:

    volatile char TESTREG @0x34;

    _Bool TESTREG_7 @TESTREG:7;

    while (!TESTREG_7);

    this will translate exactly in your asm sequence if optimizations are turned on (that is, in mode RELEASE; Cosmic suggest to never use the mode debug for st7, because it's basically useless)

    I'll check why the asm does not work as expected and let you know asap.

    Regards,

    Luca (Cosmic)

    Visitor II
    September 8, 2006
    Posted on September 08, 2006 at 13:18

    if you remove the spaces between operands your asm will compile fine even with optimizations ON.

    Regards,

    Luca

    bramAuthor
    Visitor II
    September 8, 2006
    Posted on September 08, 2006 at 18:12

    Thanks for your reply.

    I have been able to solve this issue in a different way, namely bij replacing the address 0x34 with it's named alternative _ADCCSR (the AD converter control register).

    That way the code compiled just fine. And actually about 5-10% faster than the standard while solution...