[sdcc-devel] [ sdcc-Bugs-1722426 ] Switch statement fails if inline assembler contains label

[SourceForge.net <no...@so...>]

Bugs item #1722426, was opened at 2007-05-21 04:38
Message generated for change (Comment added) made by grahamnz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1722426&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msc51(8051) target
Group: non bugs
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: GrahamNZ (grahamnz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Switch statement fails if inline assembler contains label

Initial Comment:
Hi all,
I have researched the problem described below and not found reference to it before - hence the bug report.

SDCC complier version 2.6.0 #4039 (July 28 2006)

I don't know if it is a linker or optimiser issue so have placed this report in the mcs51 category.

I have discovered that if a switch statement contains an in-line assembler block (within a case...break statement) which happens to contain a code label, as per this example...

        switch (mode)   
        {
            case MEASURING_A:
                _asm
A_label:          
                _endasm ;

                break ;
            case MEASURING_B:
                P0 = 0xFB ;
                break;

            case MEASURING_C:
                P0 = 0xFE ;
                break;
        }

then the following error message is produced (one of several examples produced for the above code):

?ASxxxx-Error-<u> in line 1047 of Switch.asm
              <u> undefined symbol encountered during assembly

Note: The presence or not of real lines of assembler code have no effect - only removing the label is effective at clearing the error.

Examination of the asm file reveals that the switch statement jump labels, although appearing in the asm file, are reported as 'undefined'.

I attach all files needed to compile the above project.

Regards,
Graham


----------------------------------------------------------------------

>Comment By: GrahamNZ (grahamnz)
Date: 2007-05-21 21:29

Message:
Logged In: YES 
user_id=1797831
Originator: YES

Hi guys,
Thanks for your help.

I have tried snapshot 2.7.0 and found the problem still exists with my
label but is OK with 0001$.

I had extensively read SDCC Manual 3.12.3, and the best I can describe is
that it is confusing. I suggest we all read it, discuss and try to
understand given the text and the example what is allowed as a label.

The text states that 'older versions of the compiler HAD TO USE nnnn$' -
this implies that this form is no longer mandatory.

Also, the example includes 'clabel:' as a label - this is outside an _asm
block so it is reasonable that it cannot be referenced inline, but my point
is that this label is obviously legal and acceptable to the compiler.

Also, we have inline elsewhere in our program:

       jbc     _TI, tx_character   ; See if we have finished sending the
last byte
       sjmp    isr_done

tx_character:
       clr     c                   ; Check for more characters to send
       mov     a, _tx_index
       subb    a, _tx_length
       jnc     isr_done
       movx    a, @dptr
       mov     _SBUF, a            ; Send the byte
       inc     _tx_index
isr_done:

and this seems to be totally acceptable to the compiler.

So, there seems to be some inconsistancy in the documentation and compiler
performance, and maybe all that is required is to clearly state that real
names cannot be used as labels. I personally feel that this would be the
wrong approach to resolve the issue.

I come back to the original point: the label inside the case part of a
switch statement corrupts the switch statement code. The same code outside
the switch statement compiles (I just tried it and can upload the code if
desired) - which in my mind confirms that there is a bug with the
switch/case/in-line label code generation.

In the interim I will continue with the old label form and try to resolve
the 'assertion failed' and 'caught signal 22: SIGABRT' errors that have now
appeared and stop the project from compiling.

Hopefully I am not being too harsh here - I think the compiler is great
and you folks perform an excellent task to us all. Together we can make a
good product even better.

Your comments welcome,
Graham


----------------------------------------------------------------------

Comment By: Borut Razem (borutr)
Date: 2007-05-21 19:49

Message:
Logged In: YES 
user_id=568035
Originator: NO

My suspicion was wrong and Jan's explanation is correct and it works.

I'm closing it since it is not a bug.

Borut

----------------------------------------------------------------------

Comment By: Borut Razem (borutr)
Date: 2007-05-21 08:38

Message:
Logged In: YES 
user_id=568035
Originator: NO

I suspect that this is a duplicate of [ 1710507 ] --i-code-in-asm makes
compile fail
https://sourceforge.net/tracker/index.php?func=detail&aid=1710507&group_id=599&atid=100599
which is already fixed. Graham, can you please try it with the latest sdcc
snapshot build?

Borut


----------------------------------------------------------------------

Comment By: wek (wek_)
Date: 2007-05-21 06:48

Message:
Logged In: YES 
user_id=1201677
Originator: NO

Graham,

Your code violates the rule for inline assembly labels (see chapter 3.12.3
of sdccman). Please retry with conformant label (of the xxxx$: form, xxxx
is a hexadecimal number less than 100).

Jan Waclawek

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1722426&group_id=599