On Sat, 10 May 2008 11:59:16 +0100, Martin Guy [EMAIL PROTECTED]
said:
On 5/9/08, Paolo Bonzini [EMAIL PROTECTED] wrote:
The idea is to use integer arithmetic to compute the right exponent, and
the lookup table to estimate the mantissa.
The current soft-fp routine in libm seems to use a
Hi all,
I was looking for ways to improve the MaverickCrunch division routine on
ARM ep93xx, and noticed that there are few other architectures that
don't have a hardware divide.
IA-64 has a frcpa instruction that returns an estimate of the
reciprocal of a float or double.
Likewise, RS-6000 has
On Tue, 15 Apr 2008 09:15:45 -0400, Daniel Jacobowitz [EMAIL PROTECTED]
said:
I'm going to keep asking until I get something we can work
with... you're reporting a bug in the compiler, so we need a test case
and the exact error message. What is generating any kind of sqrt
libcall? There
Hello all,
I've been working on MaverickCrunch support in gcc, and could never get
a completely working glibc (with-fp), since there is no soft-float sqrt
libcall function. This is a big problem for MaverickCrunch as there are
no hard div or sqrt opcodes.
It seems that this is the only other
On Mon, 14 Apr 2008 22:41:36 -0400, Daniel Jacobowitz [EMAIL PROTECTED]
said:
On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote:
Hello all,
I've been working on MaverickCrunch support in gcc, and could never get
a completely working glibc (with-fp), since there is no soft
On Mon, 14 Apr 2008 23:09:00 -0400, Daniel Jacobowitz [EMAIL PROTECTED]
said:
On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote:
Both FPA and VFP coprocessors implement sqrt opcodes:
So? Glibc does not rely on that. I've been building soft-float
versions of glibc for non
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
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
On Thu, 28 Jun 2007 14:55:17 +0200, Rask Ingemann Lambertsen
[EMAIL PROTECTED] said:
On Wed, Jun 27, 2007 at 11:26:41AM +1000, Hasjim Williams wrote:
G'day all,
As I wrote previously on gcc-patches (
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00244.html ), I'm working
on code to get
On Wed, 27 Jun 2007 08:17:47 +0200, Paolo Bonzini [EMAIL PROTECTED]
said:
if (get_attr_cirrus (prev_active_insn(insn)) == CIRRUS_COMPARE)
return \beq\\t%l0\;bvs\\t%l0\; else return \bge\\t%l0\;nop\;
[(set_attr conds jump_clob)
(set_attr length 8)]
)
As you can
On Wed, 27 Jun 2007 18:15:12 +1000, Hasjim Williams [EMAIL PROTECTED]
said:
if_then_else (ge (match_operand:CCFP 1 cc_register ) (const_int 0))
if_then_else (ge:CCFP (match_operand 1 cc_register ) (const_int 0))
Is the second line still valid syntax?
The second line doesn't work
On Wed, 27 Jun 2007 12:31:42 +0200, Rask Ingemann Lambertsen
[EMAIL PROTECTED] said:
On Wed, Jun 27, 2007 at 06:45:26PM +1000, Hasjim Williams wrote:
It also fixes up the
internal compiler error: output_operand: '%l' operand isn't a label
error...
Incidentally, does anyone know
G'day all,
As I wrote previously on gcc-patches (
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00244.html ), I'm working
on code to get the MaverickCrunch Floating-Point Co-processor supported
on ARM. I mentioned previously that you can't use the same opcodes for
testing GE on the
14 matches
Mail list logo
