[fpc-devel] Arm Thumb2 - Stellaris status

[Geoffrey Barton]

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 :)

Geoffrey

> 
> John
> 
> From: Pierre Free Pascal <pierre at freepascal.org>
> To: FPC developers' list <fpc-devel at lists.freepascal.org>
> Sent: Tue, August 9, 2011 1:00:53 PM
> Subject: RE: [fpc-devel] Arm Thumb2 - Stellaris status
> 
> 
> 
> > -----Message d'origine-----
> > De : fpc-devel-bounces at lists.freepascal.org [mailto:fpc-devel-
> > bounces at lists.freepascal.org] De la part de Geoffrey Barton
> > Envoyé : mardi 9 août 2011 10:20
> > À : FPC developers' list
> > Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status
> > 
> > 
> > On 8 Aug 2011, at 21:13, Florian Klämpfl wrote:
> > 
> > > Am 08.08.2011 12:49, schrieb John Clymer:
> > >> Kicking it around in the back of my head at work today...
> > >>
> > >> I tried doing a compile to assembly language for the stellaris - and it
> > >> choked giving the error from t_embed.pas.  The error comes from the
> > >> portion of the program trying to generate a linker script.
> > >>
> > >> Looking at t_embed.pas, it looks like every single flavor of ARM
> > >> controller will require it's own subsection of the case() statement.
> > >> This can easily get long and ugly.  As the only thing that changes
> > >> between most of the arm variants is the memory layout - why not provide
> > >> a generic "stellaris" switch - with reads in a text file containing the
> > >> memory map and stack top (the rest of the link file remains the same
> for
> > >> all variants of ARM) ?
> > >>
> > >> This way - switching to a new variant of stellaris only requires
> > >> tweaking a memory map file - rather than a re-build and patch of
> > >> t_embed.pas ?  For that matter - entirely foreign Cortex M3 parts could
> > >> be easily supported without requiring changes to the compiler.
> > >>
> > >> Just pondering how to make it easier and more flexible ...
> > >
> > > Yes, this can be done. However, somebody who knows enough about a
> > > certain controller family must do this.
> > 
> > What in your view is the best way to separate link options such as these
> > variations in memory maps between devices? I often have several projects
> at
> > once and they can be using different parts within the same family; having
> to
> > re-compile the compiler when switching between projects is not ideal.
> 
> 
>   What about adding some command line options
> similar to -WB:
>   -WB40000
> sets the default load address of Windows PE executables
> to 0x40000. Its value is stored in global variable ImageBase.
> 
> If only four or five values need to be set, we could just
> implement option -WE option:
> E for embedded, 
> with 
>   -WEFlashOriginHexDecimalValue
>   -WEFlashLengthHexDecimalValue
>   -WERamOriginHexDecimalValue
>   -WERamLengthHexDecimalValue
>   -WEStackTopHexDecimalValue
> 
> Of course, this depends if the list of required values is limited or not.
> Another problem is if the script should include or not those
> lines.
>   But here also, we could create a list of args,
> some would be tagged as having a default value, which would be used
> if no command line option is given, while other args would 
> have no default, meaning that the linker line would only be inserted
> if the corresponding value are set at command line.
>   If that case, it might be better to combine Origin and Length into a
> unique
> argument
>   -WEFlashHexValueOfOrigin-HexValueOfLength
> where HexValueOfOrigin and HexValueOfLength would both bereplaced by
> the valid values in order to avoid having only Origin and no Length for
> Flash (or Ram, or anything else that would be needed).
> 
>   Maybe a special 'custom' controller type would be handy for this...
> 
> Pierre Muller
>   
> 
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110809/4aedc9f8/attachment.html>