Bug in handling inline assembly in C Compiler

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bug in handling inline assembly in C Compiler

Jump to solution
2,565 Views
pgo
Senior Contributor V
Am I correct in thinking that the inline assembler has a problem with the '*' (current location) symbol?

Please compare the original code appearing in the left window and the disassembled code in the right-hand window. The two brclr instructions should be the same I think?

The assembler handles :

label: brclr bitnumber,ea,label

correctly

but has problems with the value of '*' in

brclr bitnumber,ea,*+0

Can anyone cast light on this?

Compiler V6.21
Target MC9S08JM60

Thanks
Labels (1)
Tags (1)
0 Kudos
1 Solution
694 Views
pgo
Senior Contributor V

Dear All,

 

FYI.

 

I believe the above bugs have been corrected in the latest version of the HCS08 Compiler (Fixed Bug MTWX31284).

 

bye

View solution in original post

0 Kudos
5 Replies
694 Views
CrasyCat
Specialist III

Hello

 

This notation is not supported by the inline assembler.

 

Is there any good reason you cannot use:

 

label: brclr bitnumber,ea,label

 

CrasyCat

0 Kudos
694 Views
pgo
Senior Contributor V

Dear CrazyCat,

 

If the notation is not accepted then the compiler should generate errors not incorrect code!  It does generate correct code for other case e.g. bra *+0.

 

This really isn't an answer :smileyhappy:  What does the assembler think '*' means in this context?

 

I have used the alternative (as shown in the original posting) but would still like an explanation.

 

I believe the compiler may be calculating the offset for the wrong HC08 variant but that's a guess.

 

bye

 

 

Message Edited by pgo on 2009-03-17 01:06 PM
Message Edited by pgo on 2009-03-17 01:12 PM
0 Kudos
694 Views
bigmac
Specialist III
Hello,

 

I have noticed some further inconsistencies on this issue -

  __asm bra * does cause an error message, whereas

  __asm bra *+0 does not cause any message, and produces the correct result, as previously noted.

 

I have not exhaustively tested, but I might presume that any of the conditional branch instructions would give the correct result.

 

  __asm brset 0,PTA,*+3 // Set/clear CF

does produce the erroneous assembly result brset 0,0x00,*+4, so is consistent with the previous observation.  Another relative branch instruction CBEQ produces a similar erroneous result.

 

  __asm jmp *+6 produces the erroneous assembly result jmp 0x06, again with no warning or error message.
 

Since the debugger extensively uses this notation within its assembly window, it does seem somewhat inconsistent to say that the notation is not supported within HLI code.

 

Regards,

Mac

0 Kudos
695 Views
pgo
Senior Contributor V

Dear All,

 

FYI.

 

I believe the above bugs have been corrected in the latest version of the HCS08 Compiler (Fixed Bug MTWX31284).

 

bye

0 Kudos
694 Views
CrasyCat
Specialist III

Hello

 

I would recommend you to submit a service request for that.

Click here to submit a service request.

Make sure to attach a reproducible project and installed product information to the service request.
To generate the required information:
- Start CodeWarrior
- Open the project
- Select "Help" -> "Pack and Go" and follow instructions on the screen.

Attach the generated .zip file to the SR.

CrasyCat

0 Kudos