<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>I was pointed to CMSIS as what to fashion things after.  The CMSIS consists of both function library and register definitions.  I've looked at CMSIS - and it is over kill for what I'm looking, yet, if I use the LM3xxxxx processor, I'm forced to having the compiled in register definitions.<br><br>Each manufacturer has it's own way of defining their registers - which may or may not be in compliance with CMSIS.  And with which each developer may or may not agree with.<br><br>By leaving the register definitions external to the compiler, then one can simply do a "uses CMSIS, LM3Sxxxx;" at the beginning of the program.  Then, it's also much easier for someone to chase down where the register they are using is defined.<br><br>I've seen registers defined in C as straight #defines -
 which prevents the register names from being used inside of GDB.  I've seen them defined individually - or as structures.  ( I prefer structures, others prefer flat.)<br><br>Each way of defining the registers has pluses and minuses.  Why restrict the end users right to decide how they want their registers defined.<br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><br>My intent with GENERIC_THUMB2 is to give someone that doesn't want to use the compilers implementation the choice to create their own.  It also gives people a way to boot strap a new Thumb2 implementation.  One can write the register definitions, then add the definitions with the start-up into the compiler.  It also gives someone a way to get started - without being a compiler writer if their MCU isn't supported.<br><br>And, as I said - I don't see how giving someone the choice of implementations is a bad
 thing.<br><br>John<br><br><div style="font-family:arial, helvetica, sans-serif;font-size:10pt"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Florian Klämpfl <florian@freepascal.org><br><b><span style="font-weight: bold;">To:</span></b> FPC developers' list <fpc-devel@lists.freepascal.org><br><b><span style="font-weight: bold;">Sent:</span></b> Sat, August 27, 2011 10:49:35 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [fpc-devel] DIFF patch for changing to table driven processor definitions for ARM<br></font><br>
Am 27.08.2011 20:33, schrieb John Clymer:<br>> I assume I speak for others, but for those of us that have been working<br>> in the embedded field for a while, some of us prefer to roll our own<br>> support code, rather than rely on compiler supplied implementations. <br>> Personnally, I've used 6 different ARM/Thumb2 cored processors in<br>> various projects.  I have NEVER used compiler or vendor provided library. <br>> <br>> I prefer NOT to use them because they add overhead, complexity, and are<br>> often times innefficient.<br><br>Well, this is not about libraries but startup code and declarations of<br>hardware registers etc. which add no overhead.<br><br>> <br>> I thought OSS was about freedom of choice.  <br><br>Yes.<br><br>> Mandating that end users<br>> follow a certain path removes their available choices.<br><br>If really needed, they can still downstrip an existing cpu unit and work<br>with a
 customized compiler. This is something a commercial compiler does<br>not allow .<br><br>> <br>> As far as custom linker maps - if one uses the Generic "controller" and<br>> tells the compiler to compile to object code, but NOT link.  Then one<br>> can provide their own linker script - with whatever crazy controller<br>> layout they desire.<br><br>This can be done with an existing cpu unit as well. After all, the code<br>*must* run on a real device.<br><br>The bare ram arm and it's memory map just looks random.<br>_______________________________________________<br>fpc-devel maillist  -  <a ymailto="mailto:fpc-devel@lists.freepascal.org" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br><span><a target="_blank" href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a></span><br></div></div>



</div></body></html>