Hello,
I´m doing a migration from 5410A to 5416 and I´m having problems
when returning from interrupt service rutines.
I don´t build the project with the -mf option (i´m using near calls
as default) because there are several vocoder funtions that we don´t want
to change so I want to keep them in the same page and call them as near.
For the rest of the program that is in another memory page we have used the
keyword far in the .h, and it seems the calls and returns are ok.
But we are having problems with the interrupt vector.
These are my settings: OVLY = 1, interrupt vector origin=0x7F80
vocvect.asm
...
dmac4: pshm XPC
nop
FB _IntBSP0Tx ; Fin tx por BSP0
vocoderrut.h
...
far interrupt void IntBSP0Tx();
While emulating I notice as if the stack was not decremented, as if XPC is not
saved in the stack, and so FRETE in ISR does not work properly.
I also tried the other way, build with -mf (far calls) and keep the mentioned
functions as near by declaring them in .h as "near void function(..)". But then
I notice that compiler translates all calls as far calls even if I declare them
as near. Is this normal?
Thanks in advance,
Lorena
ISR Far callable in 5416
Started by ●September 10, 2008
Reply by ●September 10, 20082008-09-10
Lorena-
> I'm doing a migration from 5410A to 5416 and I´m having problems
> when returning from interrupt service rutines.
>
> I don't build the project with the -mf option (i'm using near calls
> as default) because there are several vocoder funtions that we don't
> want to change so I want to keep them in the same page and call them
> as near.
Why? Using far mode your current functions aren't going to move to far memory
(beyond 64k) unless you specifically put them there via linker command (.cmd ) file.
The only "tangible" effect of far mode is a small impact on performance due to
overhead in pushing/popping XPC.
> For the rest of the program that is in another memory page we have
> used the keyword far in the .h, and it seems the calls and returns
> are ok.
> But we are having problems with the interrupt vector.
>
> These are my settings: OVLY = 1, interrupt vector origin=0x7F80
>
> vocvect.asm
> ...
> dmac4: pshm XPC
> nop
> FB _IntBSP0Tx ; Fin tx por BSP0
>
> vocoderrut.h
> ...
> far interrupt void IntBSP0Tx();
>
> While emulating I notice as if the stack was not decremented, as if
> XPC is not saved in the stack, and so FRETE in ISR does not work
> properly.
>
> I also tried the other way, build with -mf (far calls) and keep the
> mentioned functions as near by declaring them in .h as "near void
> function(..)". But then I notice that compiler translates all calls
> as far calls even if I declare them as near. Is this normal?
I know that C54x code-gen tools are not going to let you link "mixed mode" objects,
for example link your code in far mode with a library build in near mode. This would
be due to interrupts plus stack alignment -- functions that perform double-mem access
must be guaranteed an even memory boundary for stack space. This tells me that if
you were to somehow write "mixed mode" code that worked around the tool limitations,
it would be a) tricky, and b) difficult to maintain and document for other engineers
and the benefit of your company.
-Jeff
> I'm doing a migration from 5410A to 5416 and I´m having problems
> when returning from interrupt service rutines.
>
> I don't build the project with the -mf option (i'm using near calls
> as default) because there are several vocoder funtions that we don't
> want to change so I want to keep them in the same page and call them
> as near.
Why? Using far mode your current functions aren't going to move to far memory
(beyond 64k) unless you specifically put them there via linker command (.cmd ) file.
The only "tangible" effect of far mode is a small impact on performance due to
overhead in pushing/popping XPC.
> For the rest of the program that is in another memory page we have
> used the keyword far in the .h, and it seems the calls and returns
> are ok.
> But we are having problems with the interrupt vector.
>
> These are my settings: OVLY = 1, interrupt vector origin=0x7F80
>
> vocvect.asm
> ...
> dmac4: pshm XPC
> nop
> FB _IntBSP0Tx ; Fin tx por BSP0
>
> vocoderrut.h
> ...
> far interrupt void IntBSP0Tx();
>
> While emulating I notice as if the stack was not decremented, as if
> XPC is not saved in the stack, and so FRETE in ISR does not work
> properly.
>
> I also tried the other way, build with -mf (far calls) and keep the
> mentioned functions as near by declaring them in .h as "near void
> function(..)". But then I notice that compiler translates all calls
> as far calls even if I declare them as near. Is this normal?
I know that C54x code-gen tools are not going to let you link "mixed mode" objects,
for example link your code in far mode with a library build in near mode. This would
be due to interrupts plus stack alignment -- functions that perform double-mem access
must be guaranteed an even memory boundary for stack space. This tells me that if
you were to somehow write "mixed mode" code that worked around the tool limitations,
it would be a) tricky, and b) difficult to maintain and document for other engineers
and the benefit of your company.
-Jeff
Reply by ●September 12, 20082008-09-12
Thanks for your repply Jeff.
The reason why I tried to keep the project with near calls as default was that I
wanted to avoid changing the assembly vocoder functions (I didnt wrote them). I
realice that with -mf option I have to replace not only call->fcall and
ret->fret but also any other references to SP because XPC is also pushed. Am I
right?
As an example,
_Syn_Filt:
PSHM AR7
FRAME #-92
SSBX SXM
RSBX FRCT
STLM A,AR2
LDM SP,A
ADD #2,A
STLM A,AR3
MVDK *SP(94),*(AR7)
...
I have set -mf option to the project and then change some specific file options
to remove the -mf (only for the files that are calling the assembly vocoder
functions). In this way it seems to work fine.
-e _Boot -o vocoder.out -m vocoder.map -l rts_ext.lib (.cmd)
Options=-g -s -ax -mf -mx -v548 (vocoder.pjt)
["Scodec.c" Settings: "Debug"]
Options="Compiler" -{-mf}
...
Anyway I agree with you that is tricky and difficult to maintain. I would
appreciate your advice.
Lorena
-----Mensaje original-----
De: Jeff Brower [mailto:j...@signalogic.com]
Enviado el: jueves, 11 de septiembre de 2008 3:56
Para: Lorena Martin
CC: c...
Asunto: Re: [c54x] ISR Far callable in 5416
Lorena-
> I'm doing a migration from 5410A to 5416 and I´m having problems
> when returning from interrupt service rutines.
>
> I don't build the project with the -mf option (i'm using near calls
> as default) because there are several vocoder funtions that we don't
> want to change so I want to keep them in the same page and call them
> as near.
Why? Using far mode your current functions aren't going to move to far memory
(beyond 64k) unless you specifically put them there via linker command (.cmd )
file.
The only "tangible" effect of far mode is a small impact on performance due to
overhead in pushing/popping XPC.
> For the rest of the program that is in another memory page we have
> used the keyword far in the .h, and it seems the calls and returns
> are ok.
> But we are having problems with the interrupt vector.
>
> These are my settings: OVLY = 1, interrupt vector origin=0x7F80
>
> vocvect.asm
> ...
> dmac4: pshm XPC
> nop
> FB _IntBSP0Tx ; Fin tx por BSP0
>
> vocoderrut.h
> ...
> far interrupt void IntBSP0Tx();
>
> While emulating I notice as if the stack was not decremented, as if
> XPC is not saved in the stack, and so FRETE in ISR does not work
> properly.
>
> I also tried the other way, build with -mf (far calls) and keep the
> mentioned functions as near by declaring them in .h as "near void
> function(..)". But then I notice that compiler translates all calls
> as far calls even if I declare them as near. Is this normal?
I know that C54x code-gen tools are not going to let you link "mixed mode"
objects,
for example link your code in far mode with a library build in near mode. This
would
be due to interrupts plus stack alignment -- functions that perform double-mem
access
must be guaranteed an even memory boundary for stack space. This tells me that
if
you were to somehow write "mixed mode" code that worked around the tool
limitations,
it would be a) tricky, and b) difficult to maintain and document for other
engineers
and the benefit of your company.
-Jeff
The reason why I tried to keep the project with near calls as default was that I
wanted to avoid changing the assembly vocoder functions (I didnt wrote them). I
realice that with -mf option I have to replace not only call->fcall and
ret->fret but also any other references to SP because XPC is also pushed. Am I
right?
As an example,
_Syn_Filt:
PSHM AR7
FRAME #-92
SSBX SXM
RSBX FRCT
STLM A,AR2
LDM SP,A
ADD #2,A
STLM A,AR3
MVDK *SP(94),*(AR7)
...
I have set -mf option to the project and then change some specific file options
to remove the -mf (only for the files that are calling the assembly vocoder
functions). In this way it seems to work fine.
-e _Boot -o vocoder.out -m vocoder.map -l rts_ext.lib (.cmd)
Options=-g -s -ax -mf -mx -v548 (vocoder.pjt)
["Scodec.c" Settings: "Debug"]
Options="Compiler" -{-mf}
...
Anyway I agree with you that is tricky and difficult to maintain. I would
appreciate your advice.
Lorena
-----Mensaje original-----
De: Jeff Brower [mailto:j...@signalogic.com]
Enviado el: jueves, 11 de septiembre de 2008 3:56
Para: Lorena Martin
CC: c...
Asunto: Re: [c54x] ISR Far callable in 5416
Lorena-
> I'm doing a migration from 5410A to 5416 and I´m having problems
> when returning from interrupt service rutines.
>
> I don't build the project with the -mf option (i'm using near calls
> as default) because there are several vocoder funtions that we don't
> want to change so I want to keep them in the same page and call them
> as near.
Why? Using far mode your current functions aren't going to move to far memory
(beyond 64k) unless you specifically put them there via linker command (.cmd )
file.
The only "tangible" effect of far mode is a small impact on performance due to
overhead in pushing/popping XPC.
> For the rest of the program that is in another memory page we have
> used the keyword far in the .h, and it seems the calls and returns
> are ok.
> But we are having problems with the interrupt vector.
>
> These are my settings: OVLY = 1, interrupt vector origin=0x7F80
>
> vocvect.asm
> ...
> dmac4: pshm XPC
> nop
> FB _IntBSP0Tx ; Fin tx por BSP0
>
> vocoderrut.h
> ...
> far interrupt void IntBSP0Tx();
>
> While emulating I notice as if the stack was not decremented, as if
> XPC is not saved in the stack, and so FRETE in ISR does not work
> properly.
>
> I also tried the other way, build with -mf (far calls) and keep the
> mentioned functions as near by declaring them in .h as "near void
> function(..)". But then I notice that compiler translates all calls
> as far calls even if I declare them as near. Is this normal?
I know that C54x code-gen tools are not going to let you link "mixed mode"
objects,
for example link your code in far mode with a library build in near mode. This
would
be due to interrupts plus stack alignment -- functions that perform double-mem
access
must be guaranteed an even memory boundary for stack space. This tells me that
if
you were to somehow write "mixed mode" code that worked around the tool
limitations,
it would be a) tricky, and b) difficult to maintain and document for other
engineers
and the benefit of your company.
-Jeff
Reply by ●September 12, 20082008-09-12
Lorena-
> Thanks for your repply Jeff.
>
> The reason why I tried to keep the project with near calls as default was that I
> wanted to avoid changing the assembly vocoder functions (I didnt wrote them). I
> realice that with -mf option I have to replace not only call->fcall and
> ret->fret but also any other references to SP because XPC is also pushed. Am I
> right?
>
> As an example,
> _Syn_Filt:
> PSHM AR7
>
> FRAME #-92
> SSBX SXM
> RSBX FRCT
>
> STLM A,AR2
> LDM SP,A
> ADD #2,A
> STLM A,AR3
>
> MVDK *SP(94),*(AR7)
> ...
>
> I have set -mf option to the project and then change some specific file options
> to remove the -mf (only for the files that are calling the assembly vocoder
> functions). In this way it seems to work fine.
I think it's Ok as long as the function doesn't do double-word mem accesses, because
then it doesn't matter what is the stack alignment on entry.
What I did several years ago is to replace ret and call instructions with macros in
the asm functions. These macros could automatically adjust for near mode or far
mode, depending on how the project is built. I have listed these below. Note the
"adj_stack" macro and how it adds one in the case of far mode.
-Jeff
> -e _Boot -o vocoder.out -m vocoder.map -l rts_ext.lib (.cmd)
>
> Options=-g -s -ax -mf -mx -v548 (vocoder.pjt)
>
> ["Scodec.c" Settings: "Debug"]
> Options="Compiler" -{-mf}
> ...
>
> Anyway I agree with you that is tricky and difficult to maintain. I would
> appreciate your advice.
> Lorena
>
> -----Mensaje original-----
> De: Jeff Brower [mailto:j...@signalogic.com]
> Enviado el: jueves, 11 de septiembre de 2008 3:56
> Para: Lorena Martin
> CC: c...
> Asunto: Re: [c54x] ISR Far callable in 5416
>
> Lorena-
>
> > I'm doing a migration from 5410A to 5416 and I´m having problems
> > when returning from interrupt service rutines.
> >
> > I don't build the project with the -mf option (i'm using near calls
> > as default) because there are several vocoder funtions that we don't
> > want to change so I want to keep them in the same page and call them
> > as near.
>
> Why? Using far mode your current functions aren't going to move to far memory
> (beyond 64k) unless you specifically put them there via linker command (.cmd )
> file.
>
> The only "tangible" effect of far mode is a small impact on performance due to
> overhead in pushing/popping XPC.
>
> > For the rest of the program that is in another memory page we have
> > used the keyword far in the .h, and it seems the calls and returns
> > are ok.
> > But we are having problems with the interrupt vector.
> >
> > These are my settings: OVLY = 1, interrupt vector origin=0x7F80
> >
> > vocvect.asm
> > ...
> > dmac4: pshm XPC
> > nop
> > FB _IntBSP0Tx ; Fin tx por BSP0
> >
> > vocoderrut.h
> > ...
> > far interrupt void IntBSP0Tx();
> >
> > While emulating I notice as if the stack was not decremented, as if
> > XPC is not saved in the stack, and so FRETE in ISR does not work
> > properly.
> >
> > I also tried the other way, build with -mf (far calls) and keep the
> > mentioned functions as near by declaring them in .h as "near void
> > function(..)". But then I notice that compiler translates all calls
> > as far calls even if I declare them as near. Is this normal?
>
> I know that C54x code-gen tools are not going to let you link "mixed mode"
> objects,
> for example link your code in far mode with a library build in near mode. This
> would
> be due to interrupts plus stack alignment -- functions that perform double-mem
> access
> must be guaranteed an even memory boundary for stack space. This tells me that
> if
> you were to somehow write "mixed mode" code that worked around the tool
> limitations,
> it would be a) tricky, and b) difficult to maintain and document for other
> engineers
> and the benefit of your company.
>
> -Jeff
; far_mode.mac
; macros used to build far-call, far-return .asm files
; Copyright (C) Signalogic, 2001
; created: JUL 2001, JHB
ret_mac .macro
.if ($isdefed("FAR_MODE"))
.if ($isdefed("_ALG_MODE"))
far return
.else
FRET
.endif
.else
.if ($isdefed("_ALG_MODE"))
return
.else
RET
.endif
.endif
.endm
retd_mac .macro
.if ($isdefed("FAR_MODE"))
.if ($isdefed("_ALG_MODE"))
far dreturn
.else
FRETD
.endif
.else
.if ($isdefed("_ALG_MODE"))
dreturn
.else
RETD
.endif
.endif
.endm
call_mac .macro a
.if ($isdefed("FAR_MODE"))
.if ($isdefed("_ALG_MODE"))
far call a
.else
FCALL a
.endif
.else
CALL a
.endif
.endm
calld_mac .macro a
.if ($isdefed("FAR_MODE"))
.if ($isdefed("_ALG_MODE"))
far dcall a
.else
FCALLD a
.endif
.else
.if ($isdefed("_ALG_MODE"))
dcall a
.else
CALLD a
.endif
.endif
.endm
adj_stack .macro a
.if ($isdefed("FAR_MODE"))
MAR *+AR1(a+1)
.else
MAR *+AR1(a)
.endif
.endm
> Thanks for your repply Jeff.
>
> The reason why I tried to keep the project with near calls as default was that I
> wanted to avoid changing the assembly vocoder functions (I didnt wrote them). I
> realice that with -mf option I have to replace not only call->fcall and
> ret->fret but also any other references to SP because XPC is also pushed. Am I
> right?
>
> As an example,
> _Syn_Filt:
> PSHM AR7
>
> FRAME #-92
> SSBX SXM
> RSBX FRCT
>
> STLM A,AR2
> LDM SP,A
> ADD #2,A
> STLM A,AR3
>
> MVDK *SP(94),*(AR7)
> ...
>
> I have set -mf option to the project and then change some specific file options
> to remove the -mf (only for the files that are calling the assembly vocoder
> functions). In this way it seems to work fine.
I think it's Ok as long as the function doesn't do double-word mem accesses, because
then it doesn't matter what is the stack alignment on entry.
What I did several years ago is to replace ret and call instructions with macros in
the asm functions. These macros could automatically adjust for near mode or far
mode, depending on how the project is built. I have listed these below. Note the
"adj_stack" macro and how it adds one in the case of far mode.
-Jeff
> -e _Boot -o vocoder.out -m vocoder.map -l rts_ext.lib (.cmd)
>
> Options=-g -s -ax -mf -mx -v548 (vocoder.pjt)
>
> ["Scodec.c" Settings: "Debug"]
> Options="Compiler" -{-mf}
> ...
>
> Anyway I agree with you that is tricky and difficult to maintain. I would
> appreciate your advice.
> Lorena
>
> -----Mensaje original-----
> De: Jeff Brower [mailto:j...@signalogic.com]
> Enviado el: jueves, 11 de septiembre de 2008 3:56
> Para: Lorena Martin
> CC: c...
> Asunto: Re: [c54x] ISR Far callable in 5416
>
> Lorena-
>
> > I'm doing a migration from 5410A to 5416 and I´m having problems
> > when returning from interrupt service rutines.
> >
> > I don't build the project with the -mf option (i'm using near calls
> > as default) because there are several vocoder funtions that we don't
> > want to change so I want to keep them in the same page and call them
> > as near.
>
> Why? Using far mode your current functions aren't going to move to far memory
> (beyond 64k) unless you specifically put them there via linker command (.cmd )
> file.
>
> The only "tangible" effect of far mode is a small impact on performance due to
> overhead in pushing/popping XPC.
>
> > For the rest of the program that is in another memory page we have
> > used the keyword far in the .h, and it seems the calls and returns
> > are ok.
> > But we are having problems with the interrupt vector.
> >
> > These are my settings: OVLY = 1, interrupt vector origin=0x7F80
> >
> > vocvect.asm
> > ...
> > dmac4: pshm XPC
> > nop
> > FB _IntBSP0Tx ; Fin tx por BSP0
> >
> > vocoderrut.h
> > ...
> > far interrupt void IntBSP0Tx();
> >
> > While emulating I notice as if the stack was not decremented, as if
> > XPC is not saved in the stack, and so FRETE in ISR does not work
> > properly.
> >
> > I also tried the other way, build with -mf (far calls) and keep the
> > mentioned functions as near by declaring them in .h as "near void
> > function(..)". But then I notice that compiler translates all calls
> > as far calls even if I declare them as near. Is this normal?
>
> I know that C54x code-gen tools are not going to let you link "mixed mode"
> objects,
> for example link your code in far mode with a library build in near mode. This
> would
> be due to interrupts plus stack alignment -- functions that perform double-mem
> access
> must be guaranteed an even memory boundary for stack space. This tells me that
> if
> you were to somehow write "mixed mode" code that worked around the tool
> limitations,
> it would be a) tricky, and b) difficult to maintain and document for other
> engineers
> and the benefit of your company.
>
> -Jeff
; far_mode.mac
; macros used to build far-call, far-return .asm files
; Copyright (C) Signalogic, 2001
; created: JUL 2001, JHB
ret_mac .macro
.if ($isdefed("FAR_MODE"))
.if ($isdefed("_ALG_MODE"))
far return
.else
FRET
.endif
.else
.if ($isdefed("_ALG_MODE"))
return
.else
RET
.endif
.endif
.endm
retd_mac .macro
.if ($isdefed("FAR_MODE"))
.if ($isdefed("_ALG_MODE"))
far dreturn
.else
FRETD
.endif
.else
.if ($isdefed("_ALG_MODE"))
dreturn
.else
RETD
.endif
.endif
.endm
call_mac .macro a
.if ($isdefed("FAR_MODE"))
.if ($isdefed("_ALG_MODE"))
far call a
.else
FCALL a
.endif
.else
CALL a
.endif
.endm
calld_mac .macro a
.if ($isdefed("FAR_MODE"))
.if ($isdefed("_ALG_MODE"))
far dcall a
.else
FCALLD a
.endif
.else
.if ($isdefed("_ALG_MODE"))
dcall a
.else
CALLD a
.endif
.endif
.endm
adj_stack .macro a
.if ($isdefed("FAR_MODE"))
MAR *+AR1(a+1)
.else
MAR *+AR1(a)
.endif
.endm