Jump to content
Sign in to follow this  
philb

Access To Int1context And Int2context From Inline Asm

Recommended Posts

v6.95, win XP, 18f24k20

 

Now I know this is a bit odd, but...

 

I'm toying with dynamically switching the interrupt handlers, by reflashing the first 32 bytes so that the GOTO's point to different handlers.

 

So I need to have multiple instances of high and low priority interrupts. Part of the experiments in this area have been to create the correct prolog/epilog code in the new handlers... which mimics the code in the default handlers.

 

The below code compiles and links....

 

extern unsigned char Int1Context[4];

 

void my_interrupt_high (void)

{

asm

{

MOVFF _fsr0h,_Int1Context

MOVFF _fsr0l,_Int1Context+1

MOVFF _prodh,_Int1Context+2

MOVFF _prodl,_Int1Context+3

}

//stuff goes here

asm

{

MOVFF _Int1Context+3,_prodl

MOVFF _Int1Context+2,_prodh

MOVFF _Int1Context+1,_fsr0l

MOVFF _Int1Context,_fsr0h

RETFIE 1

}

}

 

But looking at the assembler output, the epilog MOVFF instructions are correctly using the '_Int1Context' symbol, while the prolog MOVFF instructions are all using some 'gbl_Int1Context' symbol, which of course is wrong. Disassembling the hex shows that the epilog is indeed correct, and the prolog code resolves the base address of 'gbl_Int1Context' to 0xFFF which is wrong. I think there are 2 errors here:

 

1) The inline assembler is inconsistent between the prolog and epilog usage of the same symbol

2) The linker doesn't complain that the 'gbl_Int1Context' doesn't actually have any storage allocated, and puts its start address to -1 (note that the extern in the code example is required to make it compile, but doesn't actually declare any storage)

 

Of course there may be a better way to achieve what I want (e.g. using the command line to have no automatic context save/restore code in the standard handlers, and then doing it all manually myself in all handlers), but that doesn't excuse the errors I'm seeing :-)

 

regards

 

Phil.

Share this post


Link to post
Share on other sites

philb,

...

But looking at the assembler output, the epilog MOVFF instructions are correctly using the '_Int1Context' symbol, while the prolog MOVFF instructions are all using some 'gbl_Int1Context' symbol, which of course is wrong. Disassembling the hex shows that the epilog is indeed correct, and the prolog code resolves the base address of 'gbl_Int1Context' to 0xFFF which is wrong. I think there are 2 errors here:

 

1) The inline assembler is inconsistent between the prolog and epilog usage of the same symbol

2) The linker doesn't complain that the 'gbl_Int1Context' doesn't actually have any storage allocated, and puts its start address to -1 (note that the extern in the code example is required to make it compile, but doesn't actually declare any storage)

...

The result do look somewhat odd. It was never intended that a user would access Int1Context in there code, so use of the linker internal data flies under the radar.

To do what you want to do reserve you own location for interrupt context storage in an unbanked area of memory eg:

char myInterruptContext[ 4 ] @ 0x10;

 

I'll add this to the bug list so that we prevent access to these internal variables.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...