This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [linux-cirrus] wot to do with the Maverick Crunch patches?

As some of you know, Cirrus is now out of the ARM business,.  Officially
April 1st.  (No joke).  We still have however

The forum will be locked, but remain for the information in it.

The site will remain.  I am now doing Linux ALSA/SoC work for our low
power audio codecs.  I have been given the freedom with this new
position to allow access to this machine for outside people to
contribute whatever works they would like.

I can add a wiki, or whatever ya'll want if you wish to use our hardware
and pipeline for WWW things.  I also have GIT, BugZilla, and some other

I personally would like to see a well-working gcc with crunch support
and will do what I can to help in that regard.

Brian Austin

-----Original Message-----
From: Martin Guy <>
To:, GCC <>, Hasjim Williams
Subject: [linux-cirrus] wot to do with the Maverick Crunch patches?
Date: Sun, 30 Mar 2008 13:45:30 +0100

Ok, so we all have dozens of these EP93xx ARM SoCs on cheap boards,
with unusable floating point hardware.

What do we have to do to get the best-working GCC support for Maverick
Crunch FPU?

Suggest: make open-source project with objective:."to get the
best-working GCC support for Maverick Crunch FPU". Anyone wanna run
one, create repositories, set up mailing list etc a la, or is the current infrastructure sufficient for a
coordinated effort?
Host the sets of patches under and endeavour to unite them?
Do we have a wiki for it, other than debian's ArmEabiPort and the wikipedia?

As I understand it, mailline GCC with patches in various versions can give:

futaris-4.1.2/-4.2.0: Can usually use floating point in hardware for C
and C++, maybe problems with exception unwinding in C++. In generated
ASM code, all conditional execution of instructions is disabled except
for jump/branch. Loss of code speed/size: negligable.
Passes most FP tests but does not produce a fully working glibc (I
gather from the Maverick OpenEmbedded people)

cirrus-latest: Conditional instructions are enabled but you can still
get inaccurate or junk results at runtime due to timing bugs in FP
hardware triggered by certain types of instructions being a certain
distance apart at runtime. Does not pass all floating point math
verification tests either, but does worse than futaris.
Cirrus also have a hand-coded Maverick libm that you can link with
old-ABI binaries - can we incorporate this asm code in mainline?

Thoughts on a postcard please... any further progress in OE land?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]