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.
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. 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. 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.) Each way of defining the registers has pluses and minuses. Why restrict the end users right to decide how they want their registers defined. 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. And, as I said - I don't see how giving someone the choice of implementations is a bad thing. John ________________________________ From: Florian Klämpfl <flor...@freepascal.org> To: FPC developers' list <fpc-devel@lists.freepascal.org> Sent: Sat, August 27, 2011 10:49:35 PM Subject: Re: [fpc-devel] DIFF patch for changing to table driven processor definitions for ARM Am 27.08.2011 20:33, schrieb John Clymer: > I assume I speak for others, but for those of us that have been working > in the embedded field for a while, some of us prefer to roll our own > support code, rather than rely on compiler supplied implementations. > Personnally, I've used 6 different ARM/Thumb2 cored processors in > various projects. I have NEVER used compiler or vendor provided library. > > I prefer NOT to use them because they add overhead, complexity, and are > often times innefficient. Well, this is not about libraries but startup code and declarations of hardware registers etc. which add no overhead. > > I thought OSS was about freedom of choice. Yes. > Mandating that end users > follow a certain path removes their available choices. If really needed, they can still downstrip an existing cpu unit and work with a customized compiler. This is something a commercial compiler does not allow . > > As far as custom linker maps - if one uses the Generic "controller" and > tells the compiler to compile to object code, but NOT link. Then one > can provide their own linker script - with whatever crazy controller > layout they desire. This can be done with an existing cpu unit as well. After all, the code *must* run on a real device. The bare ram arm and it's memory map just looks random. _______________________________________________ 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
