[Arm-netbook] FSF-Endorseable Processor

[jm]

On Mon, 2012-12-03 at 22:01 +0000, luke.leighton wrote:

> ok - to bring things more towards the direction that this long-term
> project is going, i've been talking to processor companies, and found
> the best one yet.  i'm putting together an article which introduces
> the plan, and i'd greatly appreciate peoples'  input before going
> ahead.
> 
> http://lkcl.net/articles/fsf_endorseable_processor.html
> 
> l.


Very good Luke - 100% my support :-)

I have to add this point about ARM software developer environment
duplicating and wasting precious programming
resources is a lot more atrocious than meets the eye.

ARM holdings is not defining software headers for their registers and
bit fields.

If an open source processor is developed, then we should insist that all
registers and bit fields 
are named so that when someone else makes a similar derivative processor
with different base addresses and bit field arrangements, they must use
the same
names to qualify as a compatible processor.

With that, software is portable between processors without having to
employ a vast team of engineers to sift through intentional obfuscation
to buy
more time for a new processor and its market.

(ARM made something called the CMSIS library that names registers but
has not
gone to point where the register's bit fields have been named.
Also register names for similar functions between processors can be
different
which means software can't b be recompiled to a different CPU easily.)





The blurb below illustrates the problem from a programming point of
view:

For example lets say "FCR" register is found in a particular processor.
Its header would effectively be defined as this with no information
about its flags:


        typedef struct
        {
        	union
        	{
        		uint32_t	Register;
        	};
        } FCR_Register_Type;



Whereas it should be more like this:



        typedef struct
        {
        	union
        	{
        		uint32_t	Register;
        		struct
        		{
        			unsigned FIFO_E:1;
        			unsigned RX_FIFO_R:1;
        			unsigned TX_FIFO_R:1;
        			unsigned DMA_MS:1;
        
        			unsigned Reserved4_5:2;
        			unsigned RX_TL:2;
        		};
        	};
        } FCR_Register_Type;


The problem being the latter is my own invention. 
So, you might disagree and call it the first bit field FIFO, second
field RX_FIFO, third field TX_FIFO, and so on like this:


        typedef struct
        {
        	union
        	{
        		uint32_t	Register;
        		struct
        		{
        			unsigned FIFO:1;            // different 
        			unsigned RX_FIFO:1;     // different
        			unsigned TX_FIFO:1;     // different
        			unsigned DMA:1;           // different
        
        			unsigned Reserved4_5:2;
        			unsigned RX_TL:2;
        		};
        	};
        } FCR_Register_Type;



You can immediately see, neither of us are right or wrong, but software
from two projects cannot be merged together
if everyone defined their own registers and bit fields.

Because bit fields have no name, currently it is common to see code like
this


        LPC_IOCON->PIO1_6 &= ~0xB7;        // use hard coded numbers for
        initialising registers - cannot be debugged


In order to understand what 0xB7 does, you would need the full
datasheet!!!
Its impossible to debug.

Whereas what we really want to be seeing is code like this:


        LPC_UART3->IER = IER_RBR | IER_THRE | IER_RLS;    // use named
        bit fields to initialise registers.


If you had a fault with "IER_THRE" flag being set incorrectly,
at least you can make a text search for "IER_THRE" 
before having to read the full datasheet or apply more extreme debugging
techniques to find a fault.


So what we need with an FSF endorsed processor is headers for the CPU
registers and flags which must be
carried to new processors in a way that preserves its meaning and for
this information
to be published with the public availability of the processor so that
others can port their code
to the new processor immediately instead of having to wait years for
that information to be released.

If this is not done the CPU makers are going to see this loophole as an
opportunity to once
again lock up everything by releasing myriads of CPUs with small
variations in register arrangement
or flag arrangements that wouldn't allow anything else to compile and
run on their machines
buying time for them, calculated in years again, to thwart open source
projects.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20121204/aaa829bc/attachment.html