[LLVMdev] Proposal: function prefix data

[Jim Grosbach]

On Jul 18, 2013, at 12:23 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> wrote:

> As much as I like this idea for it's use in languages with type systems like Haskell and Scheme, this proposal would limit LLVM to non-Harvard architectures. That's generally a really small minority of all processors, but it would mean there could never be a clang-avr.
> 

LLVM already effectively assumes a unified address space. The pointer address space attributes and such come close to what would be required for good Harvard support, but it’s not enough. In particular there’s the fundamental assumption that all pointers are the same size. For embedded Harvard arches, that’s often not the case.

-JIm

> An alternative you could use is, instead of using the function pointer as the variable where you are referring to a function, you could have the variable be a pointer to a static struct with the data and the actual function pointer. Basically, it's like how static class variables as handled in C++.
> 
> I don't know LLVM IR, so I'll use C to explain.
> 
> Instead of this:
> 
> void func(void){}
> 
> int main(){
>    func();
>    return 0;
> }
> 
> You could do this:
> 
> void func(void){}
> 
> /* You have to initialize this at compile time. */
> struct {
> char* data;
> int len;
> void (*ptr)(void) = func;
> } func_data;
> 
> int main(){
>    func_data.ptr();
>    return 0;
> }
> 
> On Jul 18, 2013 12:47 PM, "Jevin Sweval" <jevinsweval at gmail.com> wrote:
> On Wed, Jul 17, 2013 at 9:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> >
> > To maintain the semantics of ordinary function calls, the prefix data
> > must have a particular format.  Specifically, it must begin with a
> > sequence of bytes which decode to a sequence of machine instructions,
> > valid for the module's target, which transfer control to the point
> > immediately succeeding the prefix data, without performing any other
> > visible action.  This allows the inliner and other passes to reason
> > about the semantics of the function definition without needing to
> > reason about the prefix data.  Obviously this makes the format of the
> > prefix data highly target dependent.
> 
> 
> What if the prefix data was stored before the start of the function
> code? The function's symbol will point to the code just as before,
> eliminating the need to have instructions that skip the prefix data.
> 
> It would look something like:
> | Prefix Data ... (variable length) | Prefix Data Length (fixed length
> [32 bits?]) | Function code .... |
> 
>             ^ function symbol points here (function code)
> 
> I hope the simple ASCII art makes it through my mail client.
> 
> To access the data, you do
> 
> prefix_data = function_ptr - sizeof(prefix_length) - prefix_length
> 
> Cheers,
> Jevin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130719/9ed7bcba/attachment.html>