[fpc-devel] Arm Thumb2 - Stellaris status

[John Clymer]

I found FPC_HAS_SYSTEMS_INTERRUPT_TABL, enabled it - but it was still broken for 
Thumb2 (stellaris, stm32).

For Thumb2, it was broken in the following ways:

1) Stack_top should be placed at vector 0.
2) Each address should have the LSB set - to "force" Thumb mode when the PC gets 
loaded with that value.

I defined FPC_HAS_SYSTEMS_INTERRUPT_TABLE a little further down - so that was 
only enabled on ARM and AVR (trying not to break other things...)

I also have some added logic in ncgutil - for M3 devices - to place the 
stack_top into vector 0, then place handlers for vectors 1 to TOP.  The 
WriteVector routine for Thumb also adds an offset of 1 to each vector - so as to 
force Thumb mode upon load to PC.

John




________________________________
From: Jeppe Græsdal Johansen <jjohan07 at student.aau.dk>
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Sent: Sun, August 21, 2011 7:27:48 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status

 Den 21-08-2011 17:06, Geoffrey Barton skrev: 

>
>On 21 Aug 2011, at 15:33, John Clymer wrote:
>
>As part of my                   table-ization of cpuinfo.pas, I am including a 
>generic                   part for each (no code published for this yet.)  The                   
>caveat to this is that FLASH size and SRAM sizes are                   just set 
>to extremely large (1 MB each for now).                    Which means if the 
>code size exceeds the space of the                   device - the 
>compiler/linker will not catch the                   overflow of the available 
>resource.  (Running objsize                   on the ELF file will display the 
>sizes - so I just run                   that after every successful compile.)
>>

As I pointed out, this will always fail because the stacktop is         set 
beyond the available ram. It will cause an exception I         think. How do you 
propose to be able to set the actual ram top         for the generic part, or am 
I missing something?
>
>
>
>>Also, still testing, but I have the "interrupt" reserved                   word 
>>working (more or less, more testing needed.)                    This takes the 
>>interrupt codeword with an integer.                    The integer is the offset 
>>into the vectors table.  If                   no interrupt is provided for the 
>>given address, it                   defaults to DefaultHandler in the startup 
>>file - which                   is just a continual loop - so one can breakpoint 
>>on                   it.  (This can be enabled / disabled via a define in                   
>>the source.)  This is should only be enabled for the                   embedded 
>>target - but I need to double check to ensure                   that is the 
>>case.
>>

This is a useful development; ideally the integer would be         backed by an 
enumeration as it is a big table. One thing which I         did find missing was 
the interrupt enable and disable assembler         codes, so I patched them with 
data bytes hidden in functions.         The keil C compiler does not like these 
if you link to units         doing this (throws a data/code wobbly). See the 
file attached to         bug tracker ID0017365 for how I hacked           
interrupts.
The CPS* instruction with the correct operand syntax was added in     #18334

SVN trunk already has experimental support for the interrupt     keyword. It's 
enabled with FPC_HAS_SYSTEMS_INTERRUPT_TABLE in     fpcdefs.inc. I discovered a 
small bug with the current     implementation which is fixed with the attached 
patch(which also     includes some other stuff... the bugfix is in ncgutil. It 
didn't     search the program file for interrupt handlers before)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110821/f1ccb2dc/attachment.html>