[fpc-devel] Arm Thumb2 - Stellaris status

[Florian Klämpfl]

Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen:
> On 09-08-2011 15:53, Geoffrey Barton wrote:
>>
>> On 9 Aug 2011, at 14:14, John Clymer wrote:
>>
>>> I was thinking more of a generic controller class, including a
>>> memory.def (or whatever one wants to name it) file.  That would be
>>> easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
>>> file to add the generic type.)
>>>
>>> Haven't looked into possibly a compiler option (and may easily be
>>> more trouble than a command line option):
>>> {$ARM_FLASH_START xxxxxxxx}
>>> {$ARM_FLASH_LENGTH xxxxxxxx}
>>> {$ARM_SRAM_START xxxxxxxx}
>>> {$ARM_SRAM_LENGTH xxxxxxxx}
>>>
>>> But, I still think a static memory definition file would require the
>>> least amount of code changes.  And would only effect only the ARM
>>> related files.
>>
>> The compiler option works well when you have conditional options for
>> different target builds using ifdefs, which I do I lot. It makes it
>> very easy to see if it is in the source file as it can be locked to
>> other options and you only need to select it in one place.
>>
>> A separate linker file starts to make FPC handle like any other
>> compiler :( instead of the joy to use it is :)
> I agree. Keeping the configurations in code is easier to manage,

Yes. I think as well that everything should stick in the compiler. FPC
is open source, so no need for a convolution of compiler support and
external files. Full support of all devices will lead to a huge number
of interwinded include files in the rtl anyways.

> compared to the spiderweb of magically named files of other embedded
> compilers
> 
> I think that maybe creating an abstract class hierachy of chip families,
> instead of the current solution of a single large case statement, would
> be a better solution in the long run

Well, it can be done also by some sets like
controllers_stellaris128flash64ram. I don't think that a big full
fledged class hierary is needed. Even the case statement might be
sufficient.