[LLVMdev] STM8 backend for Clang

[Eli Friedman]

On Tue, Feb 22, 2011 at 10:59 AM, Andreas Färber <andreas.faerber at web.de> wrote:
> Am 21.02.2011 um 02:44 schrieb Eli Friedman:
>
>> On Sun, Feb 20, 2011 at 4:23 PM, Andreas Färber <andreas.faerber at web.de>
>> wrote:
>>>
>>> The first issue I stumbled upon was that the Program Counter register
>>> is 24 bits. [...]
>>
>> [...] if the only
>> 24-bit register is the program counter, you could probably get away
>> with pretending it's a 32-bit register.
>>
>>> Further, as pointer width I chose 16 bits since there currently seems
>>> to be no way to distinguish between near and far pointers?
>>
>> LLVM doesn't support distinguishing between near and far pointers.
>> Depending on how much work you want to put in and what exactly you're
>> trying to build, you might be able to get away with just pretending
>> all pointers are near and implementing __builtin_stm8_far_loadn() and
>> __builtin_stm8_far_storen() intrinsics, though.
>
> The example C code uses far pointers, e.g., to set up interrupt vectors:
>
> typedef void @far (*interrupt_handler_t)(void);
>
> struct interrupt_vector
> {
>  unsigned char interrupt_instruction;
>  interrupt_handler_t interrupt_handler;
> };
>
> So I do need support for 24-bit pointers in the Clang frontend, in order for
> the struct to fill four bytes here.
> Not sure how intrinsics could help there. I assume that @far is a
> non-standard keyword. Is it possible to derive a new language standard
> similar to GCC's --std=gnu99 to handle such extensions? The only guide I
> could find was on how to add an attribute...

You can add extensions that are enabled for only a particular target;
it's just that adding new syntax tends to be a lot of work.  Builtins
are a lot easier to implement. :)

As for how to do it, just start with parsing and work your way down
the pipeline; there isn't any guide because the specifics tend to vary
a lot with the extension you're implementing.

-Eli