| View previous topic :: View next topic |
| Author |
Message |
dtemplar
Joined: 16 Feb 2004
Posts: 5
|
| Why does the compiler insert a NOP at the beginning of a fcn |
 Posted: Mon Feb 16, 2004 4:31 am |
 |
|
I have my code somewhat like this:
#org 508, 520 auto=on
void _fcn()
{
#asm
code1
code2
...
#asm
}
and I get this disassembly:
0x508 NOP
0x50A code1
0x50C code2
0x50E ...
Now my question is what's the NOP doing there?
tnx. |
|
 |
Ttelmah
Guest
|
| Re: Why does the compiler insert a NOP at the beginning of a |
| Posted: Mon Feb 16, 2004 5:07 am |
|
|
| dtemplar wrote: |
I have my code somewhat like this:
#org 508, 520 auto=on
void _fcn()
{
#asm
code1
code2
...
#asm
}
and I get this disassembly:
0x508 NOP
0x50A code1
0x50C code2
0x50E ...
Now my question is what's the NOP doing there?
tnx. |
It is making it work!...
If you read the 'errata' sheet for some chips like the 18Fxx2, there is a fault, for which the 'bodge round' (from MicroChip), is to require the insertion of an 'FFFF' (which executes as a 'NOP', but is not a normal NOP instruction), as the first instruction for any call or goto destination.
There is a similar bodge required for table read operations.
The fix is only needed if your code uses addresses beyond 0x4000 (if not, you can turn the bodge off with the device editor).
The compiler inserts the fix for all chips where the fault is known.
When the compiler first appeared for some of these chips, there were continuous 'oddities', and while a lot of them were faults with the compiler, a few were faults with the chip. When this fix appeared, the reliability of the code improved massively.
Best Wishes |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Mon Feb 16, 2004 7:19 am |
|
|
This error which is readily apparent in any code that crosses the 4000
address and should have resulted in a recall of all these chips. As Ttelmah
says CCS have patched it. This error points out very serious quality and testing failures at Microchip and without the pain inflicted by a costly recall I don't see why the situation will change going forward. In future the purchasers of Microchip parts could again pay in full for a defective part and pay again for updates to compilers to cover it over. Now there is no such thing as perfection but this addressing flaw is way too big an error to have been merely dumped in errata. What's next for errata " shift instructions don't work in xxxx devices". My problem with the 4000 error was that everybody but Microchip lost time and money on it. |
|
|
dtemplar
Joined: 16 Feb 2004
Posts: 5
|
|
| Posted: Mon Feb 16, 2004 9:06 pm |
|
|
Thanks guys!
 |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
