Subject: Re: Floating point performance
To: None <port-arm32@NetBSD.ORG>
From: Robert Black <r.black@IC.AC.UK>
List: port-arm32
Date: 07/02/1996 10:17:03
On Jul 1, 7:44pm, Rik Griffin wrote:
> Subject: Re: Floating point performance
> In message <9607011038.ZM10280@warhol.me> you wrote:
>
> > On Jun 30, 12:38am, Rik Griffin wrote:
> > >
> > > I was going to provide some 'real world' figures for you from POVray,
> > > but for some reason it doesn't seem to like RiscBSD :-(
> > > It compiles fine, but on running, crashes out with a data abort, at
> > > address 0x0000000c. If anyone can help, I can provide more info.
> >
> > This looks like the same problem as with X. I think it is something to do
with
> > signal delivery, but as I haven't been able to reproduce it reliably I
haven't
> > got very far with tracing it. If you have a test case which reliably
produces
> > the problem I'm sure Mark would like to know about it.
>
> Well, compile the standard unix version of POVray, it needs no mods, and
> compiles with no errors. Then try tracing the standard scene file
> 'Sunset'. This causes an immediate crash every time.
>
> Some other scene files cause a crash, but not until they have at least
> partly traced.
Thanks for the info.
> Next question about gcc for RiscBSD. Does the code conform to the APCS?
> If not (and I suspect it wouldn't), what does it conform to, and where
> can I get details please? I want to link ARM code and C together, like I
> can under RISCOS :)
Yup (well, except for the stack extent register which is meaningless). The only
oddities are that the structure alignment is 8bit rather than 32bit and the
object file format is different (so you can't link with RiscOS object files).
There will presumably be a new call standard for shared libraries but as long
as you stick to a.out staticly linked executables you should be fine.
Cheers
Rob Black
--