[llvm-dev] TableGen operand question

[Jim Grosbach via llvm-dev]

Hi Dawid,

Oh, wow. Flashback time.

PIC18 is unfortunately not a good candidate for an LLVM backend. The separation of program and data memory in the ISA, accumulator based design, and banked data memory are the heavy hitters, but there’s plenty more once you get further. Efficient use of access memory vs. banked memory can get “fun,” for example.

The approach you’re describing for static activation records is a good start. You don’t want to try to assign explicit memory addresses at compile time, though. Do that in the linker. Have the compiler create a symbol for the activation record, including function arguments, that callers know how to reference (no need to get fancy. use something like __Afoo for function foo or something along those lines). Then have a metadata section that records for the linker which other functions get referenced by that function (or have the linker reconstruct via relocations). Use that to build a call graph at link time and allocate the locations for those activation records so that the memory for functions which can ever be live at the same time don’t overlap. Caveats: that means no recursion and no function pointers and no variable length argument lists. Getting bank selection done efficiently for referencing the activation records is hard (for globals in general, really, but extra important for locals). Also means that no function called from the main program can be called, directly or indirectly, from an interrupt function. All of that is solvable. None of it is trivial, and very tricky corner cases abound. All that being said, if you’re going to push forwards, I strongly recommend just doing a software stack to start with. That’s what the various INC/DEC addressing modes on the INDF<n> registers were added for (well, that and better array walking for stuff like memcpy()).

Now, as an alternative, the dsPIC, PIC24 and PIC30 micros are much more amenable to an LLVM backend. There’s still some really crazy stuff to deal with (24-bit wide program memory is happy times), but it’s a much more compiler friendly instruction set and deliberately so.

-Jim


> On Jun 9, 2016, at 2:41 AM, Dawid Retkiewicz via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> As a way to learn LLVM, I'm trying to write a backend for the Microchip PIC18 8-bit microcontroller.
> On this device, the hardware stack is very small and is used only for storing function return addresses.
> A "real" software stack implementation is not very efficient because of the limited instruction set, so for all the non-reentrant functions I've decided to use a similar solution to the one used by Microchip's own XC8 compiler, which is to simulate the stack by assigning constant memory locations to every function.
> Local variables/parameters could then be accessed by using constant memory addresses. Since this microcontroller can perform most instruction directly on such addresses, this seems the most efficient way to handle the stack.
> 
> The issue I'm facing right now is how to resolve the stack addresses in the LLVM backend.
> For instance, when calling a function, I'd like to store its parameters directly in the memory area assigned to this function.
> If I understand correctly, the exact stack size (and thus the memory needed by each function) cannot be determined before the epilogue/prologue insertion pass.This means that the target memory location is not known before this step.
> 
> My idea is to create an operand that would hold an identifier of the target function and the memory offset, and replace this identifier with a real memory address in a pass after emit prologue/epilogue.
> However, I'm not sure how to achieve such thing in TableGen, and whether it's at all possible.
> I would be grateful for any tips/directions 
> 
> Thanks,
> Dawid Retkiewicz
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev