gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Small change in NSObject.m ASM needed for PowerPC build


From: Fred Kiefer
Subject: Re: Small change in NSObject.m ASM needed for PowerPC build
Date: Mon, 04 May 2009 22:07:23 +0200
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

David Ayers wrote:
> Am Sonntag, den 03.05.2009, 17:30 +0100 schrieb David Chisnall:
>> On 3 May 2009, at 17:26, Riccardo Mottola wrote:
>>
>>> David Chisnall wrote:
>>>> On i386, you need -march=i586 or higher for this to work.  The  
>>>> existing code will break at runtime, rather than link time, on an  
>>>> 80486 and earlier, and so I assume (from the fact no one has  
>>>> complained) that no one is using GNUstep on a 386/486.
>>>>
>>> Well, how old is that code? Up to about a year ago I built and used  
>>> GNUstep on a 486-class machine, although the CPU was not genuine  
>>> intel but a compatible processor which was based on 488 ISA, it did  
>>> work...
>> As I said in my other email, I was mistaken about when the atomic ops  
>> were introduced.  They should work with -march=486, not just - 
>> march=586 - it works for me with no manually-set CFLAGS or modified  
>> GNUmakefile, on GCC 4.2.
> 
> I could imagine that the distribution kernels/assemblers were configured
> to support only a subset of the features -march=486 or lower.
> 
> I think the way to move forward is to add a configure option/test which
> would fallback to a more portable yet less efficient implementation.
> 
> I can help with the configure.ac snippets if you wish.  But wrt to the
> correct implementation I'd like to defer to you.

Yes, but what would be the condition to test for and what would be the
correct behaviour then? Should we test whether we are on a i486 (or
higher) processor and then add -march=486? And what if we are actually
on a i386? And what should we do when we are on a machine where gcc does
not provide that new build in? Currently NSIncrementExtraRefCount works
slowly on such machines, but it works. With David*s change in place we
would get the same link error I am getting now. These new build ins are
quite nice, but we really need to know where they work and where not.
Or we have to keep our hands of and not use them.

I will commit that change now, but with the new gcc > 4.1 case commented
out. That way please that get a none working (or slow) solution can
enable that code locally.

Fred




reply via email to

[Prev in Thread] Current Thread [Next in Thread]