<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
On Mon, 2012-12-03 at 22:01 +0000, luke.leighton wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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.
<A HREF="http://lkcl.net/articles/fsf_endorseable_processor.html">http://lkcl.net/articles/fsf_endorseable_processor.html</A>
l.
</PRE>
</BLOCKQUOTE>
<BR>
Very good Luke - 100% my support :-)<BR>
<BR>
I have to add this point about ARM software developer environment<BR>
duplicating and wasting precious programming<BR>
resources is a lot more atrocious than meets the eye.<BR>
<BR>
ARM holdings is not defining software headers for their registers and bit fields.<BR>
<BR>
If an open source processor is developed, then we should insist that all registers and bit fields <BR>
are named so that when someone else makes a similar derivative processor<BR>
with different base addresses and bit field arrangements, they must use the same<BR>
names to qualify as a compatible processor.<BR>
<BR>
With that, software is portable between processors without having to<BR>
employ a vast team of engineers to sift through intentional obfuscation to buy<BR>
more time for a new processor and its market.<BR>
<BR>
(ARM made something called the CMSIS library that names registers but has not<BR>
gone to point where the register's bit fields have been named.<BR>
Also register names for similar functions between processors can be different<BR>
which means software can't b be recompiled to a different CPU easily.)<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
The blurb below illustrates the problem from a programming point of view:<BR>
<BR>
For example lets say "FCR" register is found in a particular processor.<BR>
Its header would effectively be defined as this with no information about its flags:<BR>
<BR>
<BLOCKQUOTE>
<FONT COLOR="#0000ff">typedef struct</FONT><BR>
<FONT COLOR="#0000ff">{</FONT><BR>
<FONT COLOR="#0000ff"> union</FONT><BR>
<FONT COLOR="#0000ff"> {</FONT><BR>
<FONT COLOR="#0000ff"> uint32_t Register;</FONT><BR>
<FONT COLOR="#0000ff"> };</FONT><BR>
<FONT COLOR="#0000ff">} FCR_Register_Type;</FONT><BR>
</BLOCKQUOTE>
<BR>
<BR>
Whereas it should be more like this:<BR>
<BR>
<BR>
<BLOCKQUOTE>
<FONT COLOR="#0000ff">typedef struct</FONT><BR>
<FONT COLOR="#0000ff">{</FONT><BR>
<FONT COLOR="#0000ff"> union</FONT><BR>
<FONT COLOR="#0000ff"> {</FONT><BR>
<FONT COLOR="#0000ff"> uint32_t Register;</FONT><BR>
<FONT COLOR="#0000ff"> struct</FONT><BR>
<FONT COLOR="#0000ff"> {</FONT><BR>
<FONT COLOR="#0000ff"> unsigned FIFO_E:1;</FONT><BR>
<FONT COLOR="#0000ff"> unsigned RX_FIFO_R:1;</FONT><BR>
<FONT COLOR="#0000ff"> unsigned TX_FIFO_R:1;</FONT><BR>
<FONT COLOR="#0000ff"> unsigned DMA_MS:1;</FONT><BR>
<BR>
<FONT COLOR="#0000ff"> unsigned Reserved4_5:2;</FONT><BR>
<FONT COLOR="#0000ff"> unsigned RX_TL:2;</FONT><BR>
<FONT COLOR="#0000ff"> };</FONT><BR>
<FONT COLOR="#0000ff"> };</FONT><BR>
<FONT COLOR="#0000ff">} FCR_Register_Type;</FONT><BR>
</BLOCKQUOTE>
<BR>
The problem being the latter is my own invention. <BR>
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:<BR>
<BR>
<BLOCKQUOTE>
<FONT COLOR="#0000ff">typedef struct</FONT><BR>
<FONT COLOR="#0000ff">{</FONT><BR>
<FONT COLOR="#0000ff"> union</FONT><BR>
<FONT COLOR="#0000ff"> {</FONT><BR>
<FONT COLOR="#0000ff"> uint32_t Register;</FONT><BR>
<FONT COLOR="#0000ff"> struct</FONT><BR>
<FONT COLOR="#0000ff"> {</FONT><BR>
<FONT COLOR="#0000ff"> unsigned FIFO:1; // different </FONT><BR>
<FONT COLOR="#0000ff"> unsigned RX_FIFO:1; // different</FONT><BR>
<FONT COLOR="#0000ff"> unsigned TX_FIFO:1; // different</FONT><BR>
<FONT COLOR="#0000ff"> unsigned DMA:1; // different</FONT><BR>
<BR>
<FONT COLOR="#0000ff"> unsigned Reserved4_5:2;</FONT><BR>
<FONT COLOR="#0000ff"> unsigned RX_TL:2;</FONT><BR>
<FONT COLOR="#0000ff"> };</FONT><BR>
<FONT COLOR="#0000ff"> };</FONT><BR>
<FONT COLOR="#0000ff">} FCR_Register_Type;</FONT><BR>
</BLOCKQUOTE>
<BR>
<BR>
You can immediately see, neither of us are right or wrong, but software from two projects cannot be merged together<BR>
if everyone defined their own registers and bit fields.<BR>
<BR>
Because bit fields have no name, currently it is common to see code like this<BR>
<BR>
<BLOCKQUOTE>
<FONT COLOR="#0000ff">LPC_IOCON->PIO1_6 &= ~0xB7; // use hard coded numbers for initialising registers - cannot be debugged</FONT><BR>
</BLOCKQUOTE>
<BR>
In order to understand what 0xB7 does, you would need the full datasheet!!!<BR>
Its impossible to debug.<BR>
<BR>
Whereas what we really want to be seeing is code like this:<BR>
<BR>
<BLOCKQUOTE>
<FONT COLOR="#0000ff">LPC_UART3->IER = IER_RBR | IER_THRE | IER_RLS; // use named bit fields to initialise registers.</FONT><BR>
</BLOCKQUOTE>
<BR>
If you had a fault with "IER_THRE" flag being set incorrectly,<BR>
at least you can make a text search for "IER_THRE" <BR>
before having to read the full datasheet or apply more extreme debugging techniques to find a fault.<BR>
<BR>
<BR>
So what we need with an FSF endorsed processor is headers for the CPU registers and flags which must be<BR>
carried to new processors in a way that preserves its meaning and for this information<BR>
to be published with the public availability of the processor so that others can port their code<BR>
to the new processor immediately instead of having to wait years for that information to be released.<BR>
<BR>
If this is not done the CPU makers are going to see this loophole as an opportunity to once<BR>
again lock up everything by releasing myriads of CPUs with small variations in register arrangement<BR>
or flag arrangements that wouldn't allow anything else to compile and run on their machines<BR>
buying time for them, calculated in years again, to thwart open source projects.<BR>
<BR>
</BODY>
</HTML>