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 <pie...@freepascal.org> To: FPC developers' list <fpc-devel@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-boun...@lists.freepascal.org [mailto:fpc-devel- > boun...@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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel