[fpc-devel] Interrupt vector table generation
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Mon Mar 7 09:43:01 CET 2011
Jeppe Johansen wrote:
> As I wrote a while back, I would like to make it easier to handle
> interrupts when using fpc for embedded work
> The current solution is to use procedure variables with indirect jumps
> in inline assembler. While that works okay it takes up a lot of space on
> devices with lots of interrupts, and introduces unnecessary interrupt
> latencies
>
> An idea would be to use weak linking, and while it's possible in
> external assembler, a nicer solution would be to handle it in procedure
> directives. That would mean addition of some functionality that is
> generally unportable and ambiguous across platforms. So I've moved away
> from this idea for now
>
> A better idea, I think, is to use the old interrupt procedure directive.
> For some embedded platforms simply allow also specifying a interrupt
> vector/index after the interrupt keyword. Ex:
>
> procedure USARTRxInterrupt; interrupt 10;
> begin
> // Handler code
> end;
>
> And from that automatically generate an interrupt vector table in the
> compiler when compiling a program. Those tables of course look different
> for each targetted architecture, but usually they are either tables of
> branch instructions or addresses. For embedded work you'll specify the
> controllertype anyway, and that way know how large the table is, and
> what kind of vector to use
>
> Further, a future benefit of using the interrupt keyword could be
> generation of procedure exit code. Some platforms need a special "return
> from exception/interrupt" instructions at the end of interrupt handlers
I'm not sure that this belongs in a core language, because (a) the whole
concept of interrupts is non-portable, (b) the precise point at which
the vector (or equivalent) is installed is determined by the logic of
the program, and (c) it says nothing about disabling interrupts while
the vector is updated or what to do with the interrupt controller
afterwards.
Being able to mark a procedure as preserving all registers is highly
useful, and saves a lot of messing with assembler. What I've done in the
past (on x86 protected mode) was to build the final binary as an
NE-format .exe with entry points exported by name, then use a final
builder/binder stage (loosely patterned after Intel's) that set up all
vectors etc.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-devel
mailing list