[fpc-devel] Arm Thumb2 - Stellaris status

[John Clymer]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110809/ff62b1f2/attachment.html>