[Arm-netbook] FSF-Endorseable Processor

luke.leighton luke.leighton at gmail.com
Tue Dec 4 10:11:44 GMT 2012


On Tue, Dec 4, 2012 at 9:40 AM, jm <joem at martindale-electric.co.uk> wrote:
> 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 :-)

 thanks.

> 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.

 hmmm... and neither are its licensees.

> 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.

 been there... usually with reverse-engineering though, because the
headers certainly aren't available there!

> 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.

 ok.  all right sah.  point well made.

l.



More information about the arm-netbook mailing list