LLVM and Interrupt Service Routines.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

LLVM and Interrupt Service Routines.

sanjiv gupta-2
Hi,
Apparently, there is no explicit support for ISRs in the llvm framework.  I could not find a matching attribute that can be used to mark a function as an ISR, which codegen and optimizer can use accordingly. ISRs aren't called explicity from any function, so currently the optimizer deletes them. We are planning to introduce a new "interrupt" attribute (to be modeled similiar to "section" attribute) which one can use in different passes suitably.
How does that sound? Or do we have something available already?
 
- Sanjiv
 

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Andrew Lenharth
We've used the used attribute to ensure they are not deleted and had no problem.

Andrew

On Tue, Jul 21, 2009 at 10:07 AM, <[hidden email]> wrote:

> Hi,
> Apparently, there is no explicit support for ISRs in the llvm framework.  I
> could not find a matching attribute that can be used to mark a function as
> an ISR, which codegen and optimizer can use accordingly. ISRs aren't called
> explicity from any function, so currently the optimizer deletes them. We are
> planning to introduce a new "interrupt" attribute (to be modeled similiar to
> "section" attribute) which one can use in different passes suitably.
> How does that sound? Or do we have something available already?
>
> - Sanjiv
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Samuel Crow
In reply to this post by sanjiv gupta-2
Hello Sanjiv,

Have you tried attribute((used))?

--Sam

From: "[hidden email]" <[hidden email]>
To: [hidden email]
Sent: Tuesday, July 21, 2009 10:07:53 AM
Subject: [LLVMdev] LLVM and Interrupt Service Routines.

Hi,
Apparently, there is no explicit support for ISRs in the llvm framework.  I could not find a matching attribute that can be used to mark a function as an ISR, which codegen and optimizer can use accordingly. ISRs aren't called explicity from any function, so currently the optimizer deletes them. We are planning to introduce a new "interrupt" attribute (to be modeled similiar to "section" attribute) which one can use in different passes suitably.
How does that sound? Or do we have something available already?
 
- Sanjiv
 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Alex Karahalios
In reply to this post by sanjiv gupta-2
Hi Sanjiv,

Assuming that that support for Ada in LLVM is complete, I would look to see if there is something that is done there. Ada provides two pragmas (Interrupt_Handler & Attach_Handler) which allow you to both statically and dynamically attach interrupts to procedures.

Alex Karahalios

On Jul 21, 2009, at 8:07 AM, <[hidden email]> <[hidden email]> wrote:

Apparently, there is no explicit support for ISRs in the llvm framework.  I could not find a matching attribute that can be used to mark a function as an ISR, which codegen and optimizer can use accordingly. ISRs aren't called explicity from any function, so currently the optimizer deletes them. 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Sandeep Patel
In reply to this post by sanjiv gupta-2
Anton recently added support for __attribute__((naked)) in r76198 and
r76201. I'd imagine that the GCC "interrupt" and "isr" synonyms would
go in similarly. How each target handles the code generation
differences will be the interesting part.

deep

On Tue, Jul 21, 2009 at 3:07 PM, <[hidden email]> wrote:

> Hi,
> Apparently, there is no explicit support for ISRs in the llvm framework.  I
> could not find a matching attribute that can be used to mark a function as
> an ISR, which codegen and optimizer can use accordingly. ISRs aren't called
> explicity from any function, so currently the optimizer deletes them. We are
> planning to introduce a new "interrupt" attribute (to be modeled similiar to
> "section" attribute) which one can use in different passes suitably.
> How does that sound? Or do we have something available already?
>
> - Sanjiv
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Sylvere Teissier-3
> How each target handles the code generation
> differences will be the interesting part.

Why not use a target specific calling convention?

An interrupt is like a normal function call, it only has a different
calling convention.



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Alireza.Moshtaghi
PIC16 is a slightly different animal. It is not only the entry and exit
part of the ISR that are important; also the ISR has to be placed at a
certain location in memory. In addition, since PIC16 does not have a
stack, we have to play few tricks to provide reentrancy for library and
intrinsic functions that are called from ISR as well because save and
restore is also very expensive on these processors. So I don't think
calling convention is a good idea for us.

A.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
On

> Behalf Of Sylvere Teissier
> Sent: Tuesday, July 21, 2009 10:24 AM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] LLVM and Interrupt Service Routines.
>
> > How each target handles the code generation
> > differences will be the interesting part.
>
> Why not use a target specific calling convention?
>
> An interrupt is like a normal function call, it only has a different
> calling convention.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

sanjiv gupta-2
In reply to this post by Andrew Lenharth
Re: [LLVMdev] LLVM and Interrupt Service Routines.
 


From: [hidden email] on behalf of Andrew Lenharth
Sent: Tue 7/21/2009 8:43 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] LLVM and Interrupt Service Routines.

>We've used the used attribute to ensure they are not deleted and had no problem.

>
Andrew

how does code gen distinguish ISRs?

- sanjiv

On Tue, Jul 21, 2009 at 10:07 AM, <[hidden email]> wrote:


> Hi,
> Apparently, there is no explicit support for ISRs in the llvm framework.  I
> could not find a matching attribute that can be used to mark a function as
> an ISR, which codegen and optimizer can use accordingly. ISRs aren't called
> explicity from any function, so currently the optimizer deletes them. We are
> planning to introduce a new "interrupt" attribute (to be modeled similiar to
> "section" attribute) which one can use in different passes suitably.
> How does that sound? Or do we have something available already?
>
> - Sanjiv
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Duncan Sands
In reply to this post by Alex Karahalios
Hi Alex,

> Assuming that that support for Ada in LLVM is complete, I would look to
> see if there is something that is done there. Ada provides two pragmas
> (Interrupt_Handler & Attach_Handler) which allow you to both statically
> and dynamically attach interrupts to procedures.

the interrupt handler itself is a parameterless procedure that does not
return a value.  As such, I guess calling conventions and so forth are
not very relevant for it :)  In any case llvm-gcc and gcc mainline seem
to output the interrupt handler as an ordinary function on x86-32-linux.

Ciao,

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Jakob Stoklund Olesen-2
Duncan Sands <[hidden email]> writes:

> the interrupt handler itself is a parameterless procedure that does not
> return a value.  As such, I guess calling conventions and so forth are
> not very relevant for it :)  In any case llvm-gcc and gcc mainline seem
> to output the interrupt handler as an ordinary function on
> x86-32-linux.

There can be significant differences between an interrupt handler and a
void f(void) function.  An interrupt handler may have to:

- Save /all/ registers, including those that are normally caller saved.
- Use a special return instruction (RETI).
- Step over the "red zone" on the stack.
- Set up a safe stack frame before calling normal functions.

I usually write the first level interrupt handler in assembler, and then
call normal C function from there.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Chris Lattner-2

On Jul 24, 2009, at 8:47 AM, Jakob Stoklund Olesen wrote:

> Duncan Sands <[hidden email]> writes:
>
>> the interrupt handler itself is a parameterless procedure that does  
>> not
>> return a value.  As such, I guess calling conventions and so forth  
>> are
>> not very relevant for it :)  In any case llvm-gcc and gcc mainline  
>> seem
>> to output the interrupt handler as an ordinary function on
>> x86-32-linux.
>
> There can be significant differences between an interrupt handler  
> and a
> void f(void) function.  An interrupt handler may have to:
>
> - Save /all/ registers, including those that are normally caller  
> saved.
> - Use a special return instruction (RETI).
> - Step over the "red zone" on the stack.
> - Set up a safe stack frame before calling normal functions.
>
> I usually write the first level interrupt handler in assembler, and  
> then
> call normal C function from there.

Wouldn't a custom calling convention work for all of these requirements?

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Jakob Stoklund Olesen-2
Chris Lattner <[hidden email]> writes:

> On Jul 24, 2009, at 8:47 AM, Jakob Stoklund Olesen wrote:
>> - Save /all/ registers, including those that are normally caller  
>> saved.
>> - Use a special return instruction (RETI).
>> - Step over the "red zone" on the stack.
>> - Set up a safe stack frame before calling normal functions.
>>

> Wouldn't a custom calling convention work for all of these requirements?

Yes, I would think so.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Duncan Sands
In reply to this post by Jakob Stoklund Olesen-2
Hi Jakub,

> There can be significant differences between an interrupt handler and a
> void f(void) function.  An interrupt handler may have to:
>
> - Save /all/ registers, including those that are normally caller saved.
> - Use a special return instruction (RETI).
> - Step over the "red zone" on the stack.
> - Set up a safe stack frame before calling normal functions.
>
> I usually write the first level interrupt handler in assembler, and then
> call normal C function from there.

an Ada interrupt handler is registered using an Ada library routine.
The library might in fact route the interrupt to some assembler code
like you describe, which itself would then call the registered handler.
I don't know the details of how it is all made to work.

Ciao,

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Jakob Stoklund Olesen-2

On 24/07/2009, at 18.29, Duncan Sands wrote:

> an Ada interrupt handler is registered using an Ada library routine.
> The library might in fact route the interrupt to some assembler code
> like you describe, which itself would then call the registered  
> handler.
> I don't know the details of how it is all made to work.

Both are possible.

I have seen systems where it is possible to compile a function as an  
interrupt handler, and at the same time the runtime library allows you  
to hook in normal functions like you describe.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Alireza.Moshtaghi
In reply to this post by Chris Lattner-2
Please read below:

> > - Save /all/ registers, including those that are normally caller
> > saved.
> > - Use a special return instruction (RETI).
> > - Step over the "red zone" on the stack.
> > - Set up a safe stack frame before calling normal functions.
> >
> > I usually write the first level interrupt handler in assembler, and
> > then
> > call normal C function from there.
>
> Wouldn't a custom calling convention work for all of these
requirements?
>

Custom calling convention can work for the above, but for PIC16 these
are not the only things to do...
As you know PIC16 does not have stack; so generating code for ISR and
all functions that it calls (including all stdlib and basic math
intrinsics used for mult/div/etc) requires special code generation
techniques. But we don't have this information until after llvm-ld has
merged all compilation units into one. Theoretically llvm-ld can also
correct the calling convention for the two classes of functions, but I'm
not sure about the practicality of it.

Regards
Ali

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Jakob Stoklund Olesen-2

On 24/07/2009, at 19.41, <[hidden email]> wrote:

> As you know PIC16 does not have stack; so generating code for ISR and
> all functions that it calls (including all stdlib and basic math
> intrinsics used for mult/div/etc) requires special code generation
> techniques. But we don't have this information until after llvm-ld has
> merged all compilation units into one. Theoretically llvm-ld can also
> correct the calling convention for the two classes of functions, but  
> I'm
> not sure about the practicality of it.

What happens with functions that are called both inside and outside  
ISR context? Do you have to codegen two copies of those?

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

sanjiv gupta-2
Jakob Stoklund Olesen wrote:

> On 24/07/2009, at 19.41, <[hidden email]> wrote:
>
>  
>> As you know PIC16 does not have stack; so generating code for ISR and
>> all functions that it calls (including all stdlib and basic math
>> intrinsics used for mult/div/etc) requires special code generation
>> techniques. But we don't have this information until after llvm-ld has
>> merged all compilation units into one. Theoretically llvm-ld can also
>> correct the calling convention for the two classes of functions, but  
>> I'm
>> not sure about the practicality of it.
>>    
>
> What happens with functions that are called both inside and outside  
> ISR context? Do you have to codegen two copies of those?
>
>  
Yes. That's precisely what we are trying to achieve in llvm-ld.
But the problems don't end there, as llvm-ld doesn't have any idea of
libcalls (they're generated in llc) and they could also be called from
both places.

- Sanjiv

> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>  

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Chris Lattner-2

On Jul 26, 2009, at 3:42 AM, Sanjiv Gupta wrote:

>>
>> What happens with functions that are called both inside and outside
>> ISR context? Do you have to codegen two copies of those?
>>
>>
> Yes. That's precisely what we are trying to achieve in llvm-ld.
> But the problems don't end there, as llvm-ld doesn't have any idea of
> libcalls (they're generated in llc) and they could also be called from
> both places.

If you have to generate two copies of the function with different  
entrypoints, the *front-end* should handle the duplication.  This is  
just like C++ constructors.

One really old patch that apple guys experimented in the past was a  
"slow and fast call" attribute, which you could stick on function  
declarations.  If you added it to a function, the frontend would  
generate an entry point with a standard calling convention as well as  
one with a faster in-register ABI.  Direct calls would use the fast  
entry point, but if you took the address, you'd get the address of the  
normal one.

All of this was handled by the front-end, and works fine.  I think the  
patch eventually got ripped out of the compiler for other reasons  
though.

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Alireza.Moshtaghi
In reply to this post by Jakob Stoklund Olesen-2
> What happens with functions that are called both inside and outside
> ISR context? Do you have to codegen two copies of those?

Yes we have to clone these functions.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM and Interrupt Service Routines.

Alireza.Moshtaghi
In reply to this post by Chris Lattner-2
> If you have to generate two copies of the function with different
> entrypoints, the *front-end* should handle the duplication.  This is
> just like C++ constructors.
>
> One really old patch that apple guys experimented in the past was a
> "slow and fast call" attribute, which you could stick on function
> declarations.  If you added it to a function, the frontend would
> generate an entry point with a standard calling convention as well as
> one with a faster in-register ABI.  Direct calls would use the fast
> entry point, but if you took the address, you'd get the address of the
> normal one.
>
> All of this was handled by the front-end, and works fine.  I think the
> patch eventually got ripped out of the compiler for other reasons
> though.


I see 2 problems with this approach:
1 - Front end does not know which functions need to be cloned. The
cloned functions are the ones that are called both from ISR thread and
main thread; and this information is not available until all compilation
units are merged. We collect this information in a pass at the end of
llvm-ld.
2- Based on what you propose, for example the ISR thread would need to
make indirect call to cloned function; and main thread make direct call
to original function. Apart from the performance issue on PIC16 in
relation to indirect function calls, if the main thread already makes
indirect call to the function, then the same function would be called
from both threads, and the original problem is still there

A.

>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
12