LJMP "label" in 24 bit contiguous mode (80c400) appears to always compile neumonics for a LJMP 000000. What gives? LJMP immediate works fine. Anybody else run into this? 200012 02000000 F 282 LJMP LONG1 Also what does the F mean in the list? Thanks
The F means the target address is Fixed-Up by the linker. Jon
Right you are. I was reading the .lst file the hex is correct. Now is there a way to get a "complete" listing with forward/final values in the list?
OK, if you put in a LJMP Immediate in 24 bit contiguous mode, it still puts an F in the list. You would not think it needs help fixing this up.
There are several fancy linker directives that let you move things around in memory. So, even if you use immediate values for JMPs, the linker can still move them around if it knows about them. That's why this is a fixup. Jon
If you don't trust the linker, you can get a final code listing after linking, from the linker itself. It's probably not as expressive as the *.lst, though. To get it, turn on the "linker code listing" on the "listing" tab of the project options, and "linker code packing" on the C51 tab. Or, if you really want to be paranoid, get a 8051 disassembler made by someone else than Keil and run it on the final object or .hex file.
Sounds like this "linker code listing" is exactly what Im looking for. However, I have tried combinations of the check boxes you suggested, but it won't produce a .cod file. For now I can live with the fixup, later it would be nice to "see" the code exactly as mapped to memory.
If you just want to see it (as opposed to getting it written to a text file), it'll be enough to run your project in the uVision simulator and turn to the disassembly view. As to the *.cod file not being produced: you may have to turn the optimization level up beyond 8 or 9 for linker code packing to actually be done --- if it isn't the listing won't be generated, it seems.