[fpc-devel] DIFF patch for changing to table driven processor definitions for ARM

[John Clymer]

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 <florian at freepascal.org>
To: FPC developers' list <fpc-devel at 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 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/20110827/2ec11ae8/attachment.html>