llvm dev - Jul 2009 - [LLVMdev] LLVM and Interrupt Service Routines.

On Jul 24, 2009, at 8:47 AM, Jakob Stoklund Olesen wrote:
> Duncan Sands <baldrick at free.fr> 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

Chris Lattner <clattner at apple.com> 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.

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

On 24/07/2009, at 19.41, <Alireza.Moshtaghi at microchip.com> 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?

> Wouldn't a custom calling convention work for all of these
requirements?
A little bit ugly thing about this is that we'd need to spread this
support into many different places - usually this stuff will require
some custom prologue / epilogue, some custom stack frame stuff
lowering, etc.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University