On Tue, 1 Apr 2008, Hasjim Williams wrote:
That illustrates the sort of thing that needs changing to implement
unwind
support for a new coprocessor. Obviously you need to get the unwind
specification in the official ARM EABI documents first before
implementing
it in GCC
Any
That only covers call-preserved registers. Testing call-clobbered
registers is harder (but normally unwind information won't be generated
for them, so they matter less); for iWMMXt I tried testing using
-fcall-saved-wr0 -fcall-saved-wr1 ... but found that
CONDITIONAL_REGISTER_USAGE overrides
On Mon, 31 Mar 2008 15:46:52 +1000, Hasjim Williams
[EMAIL PROTECTED] said:
I don't think glibc compiles/runs if MaverickCrunch is enabled, because
of the lack of support in the glibc-2.5/ports/sysdeps/arm directory.
Yep, just tried building it again then... glibc-intermediate fails
On Mon, 31 Mar 2008, Hasjim Williams wrote:
If someone can get iwmmxt support working in everything, then we might
be able to do the same for MaverickCrunch, since it is very similar work
to get one ARM coprocessor working as it is to get another working.
Half of the support for the iWMMXt
Brian Austin wrote:
As some of you know, Cirrus is now out of the ARM business,. Officially
April 1st. (No joke). We still have however arm.cirrus.com.
What a great day to announce that. Is there an official announcement available
somewhere now? The company I work for is about to release
The libm patch is for uClibc.
-Original Message-
From: Hasjim Williams [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Martin Guy [EMAIL PROTECTED], [EMAIL PROTECTED], GCC
gcc@gcc.gnu.org
Subject: [linux-cirrus] Re: wot to do with the Maverick Crunch patches?
Date: Mon, 31 Mar 2008 15
The company I work for is about to release a board to PCB fab
with a Cirrus part on it. If this is the case we may want to hold back on
the
release and switch ARM parts.
If it's the EP93xx, you'd be well-advised to do so; I gather there is
one similar competitor that doesn't waste silicon
The libm patch is for uClibc.
This thread is now off-topic for the GCC list. Please take up the
discussion on a more appropriate list.
Thanks, Ben
On Mon, 31 Mar 2008 11:31:01 + (UTC), Joseph S. Myers
[EMAIL PROTECTED] said:
On Mon, 31 Mar 2008, Hasjim Williams wrote:
Joseph,
First of all thanks for replying to this e-mail. You seem to be the one
who has written most of the ARM coprocessor patches in the past, so
logically you're
On Tue, 01 Apr 2008 12:10:54 +1000, Hasjim Williams
[EMAIL PROTECTED] said:
gcc uses the code in unwind-arm.c etal to call the functions
(create_unwind_entry, unwind_save_mv etc) binutils gas/config/tc-arm.c
to do the frame unwinding, right? To do the unwind parsing (of table 4
from 9.3 in
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
PROTECTED]
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
On 3/30/08, Brian Austin [EMAIL PROTECTED] wrote:
I am now doing Linux ALSA/SoC work for our low power audio codecs.
Good luck, look forward to using them... :)
I have been given the freedom with this new
position to allow access to this machine for outside people to
contribute whatever
On Sun, 30 Mar 2008 13:45:30 +0100, Martin Guy [EMAIL PROTECTED]
said:
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
14 matches
Mail list logo
