On Sun, 3 Oct 2004, Adam Woodworth wrote:

> As you can see, there's 2 extraneous goto statements, one at 0003 and one
> at 0005.

They're not extraneous; it's just startup code.  They won't cause any
problems.

> And the one at 0005 jumps to a completely different area in
> memory.  So for some reason after 0005 the compiler moved the code up to
> 03fa.

That's what the compiler chose to do.  It doesn't cause a problem.

> Now if I take this assembly code and remove the gotos at 0003 and
> 0005 and compile it into .hex with gpasm, it works fine.  I can load it
> onto my PIC and the LED lights up.

I don't think that proves anything.  Did you try the same test without
modifying the assembly code?

The output you're getting matches what I get from the commercial
version of PICC on Linux.  I can import the hex file into MPLAB,
unmodified; simulating it leaves me with TRISB at 0x00 and PORTB at
0xFF, just as you'd expect.  The GOTOs don't do anything strange.
Have you tried simulating it yourself?

I can state pretty confidently that there is essentially zero
probability that your two-line program is getting compiled
incorrectly, and that trying to figure out what is "wrong" with the
output of the compiler is going to lead you nowhere.  I still say the
most likely problem is some incompatibility between the hex file and
your programming software.

Try importing the hex file into MPLAB on a Windows machine, then
exporting it, and see if the resulting DOS-formatted hex file makes
your programmer happy.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist