See cmd_out.txt file in cmd_out.tar for sample commands
and version of SDCC and Ubuntu (Linux).
Also contains sample command and output.
and other files.
See discription above
Logged In: YES
First it's not customary to put all information about your
report in an attachment. Everything you wrote in
cmd_out.txt could have been here in the report.
Second, when filing a bug report it's very welcomed to
first check if the latest version has the same problem.
Third, do not use Keil header files with SDCC.
And finally, labels starting with a digit are local
symbols. SDCC uses them and when using inline asm you
should too. The labels numerically below 00100$ are always
free for this use. If you replace all labels with 00001$,
00002$, etc. it compiles and assembles fine.
Additional warnings: C symbols need an extra underscore
when accessed from asm. And SDCC uses a totally different
Logged In: YES
Sorry about placing my documention in a attached file but
my development is under linux and my email is on a windows
I tried to follow fixes and found nothing relating to
issue of labels after an inline asmemble routine. Are you
talking about version 2.6 of SDCC?
All the include files have been modified for SDCC compiler.
The issue is the labels who's value is greater than 100
and were generated by the compiler. How do I get the
compiler to generate labels less than 100?
Or from your comment, I should reedit the output from the
compiler to change all the labels to be less than 100 and
then reasemble it? ?
P.S. How do I submit a bug that is not rejected. The tar
file if untared gives everything needed to see the error.
The txt file gives a sample of the command.
The report was not rejected because you used a tar. Indeed
it contained everything, I just disliked the extra
Yes, I was talking about 2.6 where you used 2.5. Anyway
thanks for putting that info in the first place. And no
2.6 is no different than 2.5 in this case.
The C8051F320.h you included in the tar is for Keil, not
for SDCC. Throw it away and use the one that comes with
You should not try to get the compiler to use labels below
100. That's impossible. You should also not edit the
output and renumber the local labels. What you should do
however is rename the labels in your inline asm to numbers
below 100 or at least make them start with a digit so they
are recognized as local labels too.
The assembler does not allow local labels to cross non-
local labels. The liverange of local labels is from the
previous non-local label to the next non-local label.
I hope this clears things up.
Still, I see no bug. I renamed the labels in your code and
it compiled and assembled fine.
I close the report again. If you want to continue
discussion in this thread you can also do that without
Thank You for your response. My mind was thinking the
problem was else different. I under stand, I also changed
the labels in the asm code and it compiled.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.