Re: Small change in NSObject.m ASM needed for PowerPC build
David,
now this is very strange. Your tiny program works perfectly here, even
when I change it into an Objective-C fragment. I get the expected ASM
code (or even more so). And it gives the right result.
So why is it failing in NSObject.m?
I ran this file through the preprocessor and get the following line:
result =
__sync_fetch_and_sub(((gsatomic_t)&(((obj)anObject)[-1].retained)), 1);
This looks a bit complicated but quite sensible.
Converting this into assembler gives
.loc 1 380 0
movl8(%ebp), %eax
subl$8, %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call__sync_fetch_and_su...@plt
movl%eax, -16(%ebp)
Sorry, no clue what gcc is doing here.
Next I tried to make your example more similar to the code above,
resulting in this:
#include
typedef int32_t volatile *gsatomic_t;
volatile int a;
int main(void)
{
__sync_fetch_and_add((gsatomic_t)&a, 1);
return a;
}
But that still compiles well.
.file "sync1.m"
.text
.globl main
.type main, @function
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp
pushl %ecx
lock addl $1, a
movla, %eax
popl%ecx
popl%ebp
leal-4(%ecx), %esp
ret
.size main, .-main
.local _OBJC_SELECTOR_TABLE
.comm _OBJC_SELECTOR_TABLE,8,4
.comm a,4,4
.ident "GCC: (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]"
.section.comment.SUSE.OPTs,"MS",@progbits,1
.ascii "ospwg"
.section.note.GNU-stack,"",@progbits
Any idea, what I could test next?
Fred
David Chisnall wrote:
> Can you try compiling this short C program:
>
> volatile int a;
> int main(void)
> {
> __sync_fetch_and_add(&a, 1);
> return a;
> }
>
> For me, with GCC 4.2.1, this Just Works™. If it doesn't for you, can
> you try compiling it with gcc -S and take a look at the generated .s
> file? It should contain this short sequence:
>
> lock
> addl$1, a
>
> If instead it contains:
>
> call __sync_fetch_and_add
>
> Then something weird is going on - the compiler is generating a call to
> the implementation in libgcc_s, which should only be used for non-x86
> platforms.
>
> If we can't manage to get this working in the general case, then you can
> use this little program in the configure script - if it runs and exits
> then the compiler supports this extension (both recent gcc and clang do,
> so it should become increasingly-well supported over time).
>
> I'm still surprised that it doesn't work for you - I've not had any
> problems with it for a couple of years on FreeBSD, and I was under the
> impression GCC supported Linux better than FreeBSD.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
Hi Fred,
Can you try compiling this short C program:
volatile int a;
int main(void)
{
__sync_fetch_and_add(&a, 1);
return a;
}
For me, with GCC 4.2.1, this Just Works™. If it doesn't for you, can
you try compiling it with gcc -S and take a look at the generated .s
file? It should contain this short sequence:
lock
addl$1, a
If instead it contains:
call __sync_fetch_and_add
Then something weird is going on - the compiler is generating a call
to the implementation in libgcc_s, which should only be used for non-
x86 platforms.
If we can't manage to get this working in the general case, then you
can use this little program in the configure script - if it runs and
exits then the compiler supports this extension (both recent gcc and
clang do, so it should become increasingly-well supported over time).
I'm still surprised that it doesn't work for you - I've not had any
problems with it for a couple of years on FreeBSD, and I was under the
impression GCC supported Linux better than FreeBSD.
David
On 5 May 2009, at 08:46, Fred Kiefer wrote:
David Chisnall wrote:
I think it's important to work out why it is failing on your machine.
The reason I suggested this change is that, for me, looking at the
assembly, it generates the same code as our inline asm on x86 but
also
works on non-x86 platforms that we currently use a painfully slow
code
path for.
I fully agree with you here.
I am using GCC 4.2.1, and this compiles correctly with no -march=
anything specified. If I specify -march=i386 it still generates the
LOCK. Looking more deeply at the ISA references, it appears that the
LOCK prefix was part of the original 80386 instruction set, so this
is
atomic on any x86 processor (it was the CMPXCHG instruction and
friends
that came in with the 80486).
That would be great, in this case, we did not loose any compatibility
with the last change and also wont with the new one.
Possibly the GCC version check is incorrect. According to the gcc
docs,
these functions appeared in 4.1.0, however it seems that 4.2 is when
they became well-supported. Possibly setting 4.2.0 or 4.2.1 as the
minimum GCC version to adopt them will be better?
Again you are correct, better require a gcc version where we can be
sure
it supports this correctly. Still this does not help on my machine,
as I
wrote in the first mail I have gcc 4.3.2 installed. Here are the
full specs:
gcc -dumpspecs
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
*asm_debug:
%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}
*asm_final:
*asm_options:
%{--target-help:%:print-asm-header()} %a %Y %{c:%W{o*}%{!o*:-o
%w%b%O}}%{!c:-o %d%w%u%O}
*invoke_as:
%{!S:-o %|.s |
as %(asm_options) %|.s %A }
*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*}
%{w} %{f*} %{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}}
%{O*} %{undef} %{save-temps:-fpch-preprocess}
*cpp_debug_options:
%{d*}
*cpp_unique_options:
%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-quiet}
%{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD
%{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM}
%{MF*} %{MG} %{MP} %{MQ*} %{MT*}
%{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}} %{remap}
%{g3|ggdb3|gstabs3|gcoff3|gxcoff3|gvms3:-dD} %{H} %C %{D*&U*&A*} %{i*}
%Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h}
%{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:
%W{o*}}
*trad_capable_cpp:
cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp}
*cc1:
%(cc1_cpu) %{profile:-p}
*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are
incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*}
%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase
%b}}
%{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version}
%{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help}
%{--target-help:--target-help} %{--help=*:--help=%(VALUE)}
%{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j}
%{-param*} %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}
%{coverage:-fprofile-arcs -ftest-coverage}
*cc1plus:
*link_gcc_c_sequence:
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}
*link_ssp:
%{fstack-protector:}
*endfile:
%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s}
%{mpc32:crtprec32.o%s}%{mpc64:crtprec64.o%s}
%{mpc80:crtprec80.o%s}%{shared|pie:crtendS.o%s;:crtend.o%s}
crtn.o%s
*link:
%{!r:--build-id} %{!static:--eh-frame-hdr} -m %(link_emulation)
%{shared:-shared} %{!shared: %{!ibcs: %{!static:
%{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker
%(dynamic_linker)}} %{static:-static}}}
*lib:
%{pthread:-lpthread}%{shared:-lc}%{!shared:%{mieee-fp:-lieee}
%{profile:-lc_p}%{!profi
Re: Small change in NSObject.m ASM needed for PowerPC build
Am Montag, den 04.05.2009, 22:07 +0200 schrieb Fred Kiefer: > > 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. > > > 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? I would think that we should add test that always compiles and links but also runs a small programm using the instructions unless were cross-compiling. But we also need a manual configuration switch so that distributions can compile for "minimal requirements" on newer machines. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
David Chisnall wrote:
> I think it's important to work out why it is failing on your machine.
> The reason I suggested this change is that, for me, looking at the
> assembly, it generates the same code as our inline asm on x86 but also
> works on non-x86 platforms that we currently use a painfully slow code
> path for.
I fully agree with you here.
> I am using GCC 4.2.1, and this compiles correctly with no -march=
> anything specified. If I specify -march=i386 it still generates the
> LOCK. Looking more deeply at the ISA references, it appears that the
> LOCK prefix was part of the original 80386 instruction set, so this is
> atomic on any x86 processor (it was the CMPXCHG instruction and friends
> that came in with the 80486).
That would be great, in this case, we did not loose any compatibility
with the last change and also wont with the new one.
> Possibly the GCC version check is incorrect. According to the gcc docs,
> these functions appeared in 4.1.0, however it seems that 4.2 is when
> they became well-supported. Possibly setting 4.2.0 or 4.2.1 as the
> minimum GCC version to adopt them will be better?
Again you are correct, better require a gcc version where we can be sure
it supports this correctly. Still this does not help on my machine, as I
wrote in the first mail I have gcc 4.3.2 installed. Here are the full specs:
gcc -dumpspecs
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
*asm_debug:
%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}
*asm_final:
*asm_options:
%{--target-help:%:print-asm-header()} %a %Y %{c:%W{o*}%{!o*:-o
%w%b%O}}%{!c:-o %d%w%u%O}
*invoke_as:
%{!S:-o %|.s |
as %(asm_options) %|.s %A }
*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*}
%{w} %{f*} %{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}}
%{O*} %{undef} %{save-temps:-fpch-preprocess}
*cpp_debug_options:
%{d*}
*cpp_unique_options:
%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-quiet}
%{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD
%{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM}
%{MF*} %{MG} %{MP} %{MQ*} %{MT*}
%{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}} %{remap}
%{g3|ggdb3|gstabs3|gcoff3|gxcoff3|gvms3:-dD} %{H} %C %{D*&U*&A*} %{i*}
%Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h}
%{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
*trad_capable_cpp:
cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp}
*cc1:
%(cc1_cpu) %{profile:-p}
*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are
incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*}
%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}}
%{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version}
%{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help}
%{--target-help:--target-help} %{--help=*:--help=%(VALUE)}
%{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j}
%{-param*} %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}
%{coverage:-fprofile-arcs -ftest-coverage}
*cc1plus:
*link_gcc_c_sequence:
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}
*link_ssp:
%{fstack-protector:}
*endfile:
%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s}
%{mpc32:crtprec32.o%s}%{mpc64:crtprec64.o%s}
%{mpc80:crtprec80.o%s}%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s
*link:
%{!r:--build-id} %{!static:--eh-frame-hdr} -m %(link_emulation)
%{shared:-shared} %{!shared: %{!ibcs: %{!static:
%{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker
%(dynamic_linker)}} %{static:-static}}}
*lib:
%{pthread:-lpthread}%{shared:-lc}%{!shared:%{mieee-fp:-lieee}
%{profile:-lc_p}%{!profile:-lc}}
*mfwrap:
%{static: %{fmudflap|fmudflapth: --wrap=malloc --wrap=free
--wrap=calloc --wrap=realloc --wrap=mmap --wrap=munmap --wrap=alloca}
%{fmudflapth: --wrap=pthread_create}} %{fmudflap|fmudflapth: --wrap=main}
*mflib:
%{fmudflap|fmudflapth: -export-dynamic}
*link_gomp:
*libgcc:
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed
-lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc
*startfile:
%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
*switches_need_spaces:
*cross_compile:
0
*version:
4.3.2
*multilib:
. ;
*multilib_defaults:
*multilib_extra:
*multilib_matches:
*multilib_exclusions:
*multilib_options:
*linker:
collect2
*link_libgcc:
%D
*md_exec_prefix:
*md_startfile_prefix:
*md_startfile_prefix_1:
*startfile_prefix_spec:
*sysroot_spec:
--sysroot=%R
*sysroot_suffix_spec:
*sysroot_hdrs_suffix_spec:
*cc1_cpu:
%{mcpu=*:-mtune=%* %n`-mcpu=' is deprecated. Use `-mtune=' or '-march='
instead.
} %http:
Re: Small change in NSObject.m ASM needed for PowerPC build
On 4 May 2009, at 22:12, Fred Kiefer wrote: Please keep in mind that my i586 is surely able to execute these instructions, still I get a link error with your latest patch. I think we agree that the aim is to get it to work out of the box on as much environments as possible. The i486 assembler code already restricted that a bit, but nobody has complained up to now (and the change has been in a full year already). The gcc build in change would break it on my machine and an unknown amount of others as well. I think it's important to work out why it is failing on your machine. The reason I suggested this change is that, for me, looking at the assembly, it generates the same code as our inline asm on x86 but also works on non-x86 platforms that we currently use a painfully slow code path for. I am using GCC 4.2.1, and this compiles correctly with no -march= anything specified. If I specify -march=i386 it still generates the LOCK. Looking more deeply at the ISA references, it appears that the LOCK prefix was part of the original 80386 instruction set, so this is atomic on any x86 processor (it was the CMPXCHG instruction and friends that came in with the 80486). Possibly the GCC version check is incorrect. According to the gcc docs, these functions appeared in 4.1.0, however it seems that 4.2 is when they became well-supported. Possibly setting 4.2.0 or 4.2.1 as the minimum GCC version to adopt them will be better? David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
David Chisnall wrote: > On 4 May 2009, at 21:07, Fred Kiefer wrote: > >> 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. > > Actually, it doesn't. If we are on i386, the original inline asm is > used. This uses instructions which are not present on 386 chips, and so > will fail at runtime. This change just means that it now fails at link > time instead, which is probably an improvement, although a small one. OK, so I have to rephrase my words, it used to work but with current code it may already fail on some machines. Please keep in mind that my i586 is surely able to execute these instructions, still I get a link error with your latest patch. I think we agree that the aim is to get it to work out of the box on as much environments as possible. The i486 assembler code already restricted that a bit, but nobody has complained up to now (and the change has been in a full year already). The gcc build in change would break it on my machine and an unknown amount of others as well. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
On 4 May 2009, at 21:07, Fred Kiefer wrote: 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. Actually, it doesn't. If we are on i386, the original inline asm is used. This uses instructions which are not present on 386 chips, and so will fail at runtime. This change just means that it now fails at link time instead, which is probably an improvement, although a small one. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
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. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
Sorry, no idea, why this fails for me. "uname -a" give this result: Linux hugo 2.6.27.21-0.1-pae #1 SMP 2009-03-31 14:50:44 +0200 i686 i686 i386 GNU/Linux But I don't know what gcc relies on. I also read somewhere that you have to use the link flag "-lgcc" to use the new build in functions, but this may be for the not so well supported platforms. Really no idea, Fred David Chisnall wrote: > Checking the ISA reference, it appears that the required atomic > instructions appeared in the 486, so -march=486 should work. I have an > almost identical patch applied locally and it builds correctly with no > modifications to the GNUmakefile, so I'm slightly confused as to why > this fails for Fred. > > David > > On 3 May 2009, at 02:53, Stefan Bidigaray wrote: > >> On Sat, May 2, 2009 at 4:10 PM, 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. >> >> Are you sure about that? Cause I've built GNUstep multiple time with >> the script here: >> http://slackbuilds.org/slackbuilds/12.2/libraries/gnustep-base/gnustep-base.SlackBuild >> >> And have never had a problem. (Note that the default will build with >> -march=486) >> >> Stefan > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
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. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
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... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
Checking the ISA reference, it appears that the required atomic instructions appeared in the 486, so -march=486 should work. I have an almost identical patch applied locally and it builds correctly with no modifications to the GNUmakefile, so I'm slightly confused as to why this fails for Fred. David On 3 May 2009, at 02:53, Stefan Bidigaray wrote: On Sat, May 2, 2009 at 4:10 PM, 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. Are you sure about that? Cause I've built GNUstep multiple time with the script here: http://slackbuilds.org/slackbuilds/12.2/libraries/gnustep-base/gnustep-base.SlackBuild And have never had a problem. (Note that the default will build with -march=486) Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
On Sat, May 2, 2009 at 4:10 PM, 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. Are you sure about that? Cause I've built GNUstep multiple time with the script here: http://slackbuilds.org/slackbuilds/12.2/libraries/gnustep-base/gnustep-base.SlackBuild And have never had a problem. (Note that the default will build with -march=486) Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
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.
David
On 2 May 2009, at 22:16, Fred Kiefer wrote:
Using this change with gcc 4.3.2 on OpenSuse 11.1 give the following
error:
Linking tool autogsdoc ...
../Source/./obj/libgnustep-base.so: undefined reference to
`__sync_fetch_and_sub_4'
../Source/./obj/libgnustep-base.so: undefined reference to
`__sync_fetch_and_add_4'
We either need to link another library or convince gcc that this is
really a build in function.
Fred
David Chisnall wrote:
Ooops, this one is my fault.
Recent versions of GCC (and llvm-gcc / clang) support portable atomic
intrinsics. I've checked these on x86 and x86-64, and they
generate the
same code that my inline asm uses. If you add this after the Windows
bit (it will probably work on Windows too, but I'm not completely
sure)
then we will gain fast atomic operations on all platforms (e.g.
SPARC /
ARM) that support them when compiling with a recent compiler.
David
#elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)
/* Use the GCC atomic operations with recent GCC versions */
typedef int32_t volatile *gsatomic_t;
#define GSATOMICREAD(X) (*(X))
#define GSAtomicIncrement(X)__sync_fetch_and_add(X, 1)
#define GSAtomicDecrement(X)__sync_fetch_and_sub(X, 1)
On 13 Apr 2009, at 10:19, Eric Wasylishen wrote:
Hi,
I ran in to a small problem when compiling GNUstep (svn trunk) on
Debian testing for PowerPC. GCC is "gcc (Debian 4.3.2-1.1) 4.3.2"
Compiling file NSObject.m ...
/tmp/ccF8zgwE.s: Assembler messages:
/tmp/ccF8zgwE.s:730: Error: symbol `modified' is already defined
make[3]: *** [obj/NSObject.m.o] Error 1
The PPC atomic increment and decrement functions starting at line
254
of NSObject.m both use the label 'modified:' in their asm code. I
found that by changing the labels in one of the functions to
something
else ("modified2"), this error disappeared.
I'm not sure if GCC is correct in reporting this as an error or not,
but it's easy to fix.
-Eric
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
Using this change with gcc 4.3.2 on OpenSuse 11.1 give the following error:
Linking tool autogsdoc ...
../Source/./obj/libgnustep-base.so: undefined reference to
`__sync_fetch_and_sub_4'
../Source/./obj/libgnustep-base.so: undefined reference to
`__sync_fetch_and_add_4'
We either need to link another library or convince gcc that this is
really a build in function.
Fred
David Chisnall wrote:
> Ooops, this one is my fault.
>
> Recent versions of GCC (and llvm-gcc / clang) support portable atomic
> intrinsics. I've checked these on x86 and x86-64, and they generate the
> same code that my inline asm uses. If you add this after the Windows
> bit (it will probably work on Windows too, but I'm not completely sure)
> then we will gain fast atomic operations on all platforms (e.g. SPARC /
> ARM) that support them when compiling with a recent compiler.
>
> David
>
> #elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)
> /* Use the GCC atomic operations with recent GCC versions */
>
> typedef int32_t volatile *gsatomic_t;
> #define GSATOMICREAD(X) (*(X))
> #define GSAtomicIncrement(X)__sync_fetch_and_add(X, 1)
> #define GSAtomicDecrement(X)__sync_fetch_and_sub(X, 1)
>
>
> On 13 Apr 2009, at 10:19, Eric Wasylishen wrote:
>
>> Hi,
>> I ran in to a small problem when compiling GNUstep (svn trunk) on
>> Debian testing for PowerPC. GCC is "gcc (Debian 4.3.2-1.1) 4.3.2"
>>
>> Compiling file NSObject.m ...
>> /tmp/ccF8zgwE.s: Assembler messages:
>> /tmp/ccF8zgwE.s:730: Error: symbol `modified' is already defined
>> make[3]: *** [obj/NSObject.m.o] Error 1
>>
>> The PPC atomic increment and decrement functions starting at line 254
>> of NSObject.m both use the label 'modified:' in their asm code. I
>> found that by changing the labels in one of the functions to something
>> else ("modified2"), this error disappeared.
>>
>> I'm not sure if GCC is correct in reporting this as an error or not,
>> but it's easy to fix.
>> -Eric
>>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
Hi,
I have attached a patch for NSObject.m which adds the GCC atomic
increment/decrement operations, and also renames the 'modified:' labels in
the existing PPC assembly increment/decrement functions so that they will
now compile if they happen to be needed.
Eric
On Mon, Apr 13, 2009 at 5:58 AM, David Chisnall wrote:
> Ooops, this one is my fault.
>
> Recent versions of GCC (and llvm-gcc / clang) support portable atomic
> intrinsics. I've checked these on x86 and x86-64, and they generate the
> same code that my inline asm uses. If you add this after the Windows bit
> (it will probably work on Windows too, but I'm not completely sure) then we
> will gain fast atomic operations on all platforms (e.g. SPARC / ARM) that
> support them when compiling with a recent compiler.
>
> David
>
> #elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)
> /* Use the GCC atomic operations with recent GCC versions */
>
> typedef int32_t volatile *gsatomic_t;
> #define GSATOMICREAD(X) (*(X))
> #define GSAtomicIncrement(X)__sync_fetch_and_add(X, 1)
> #define GSAtomicDecrement(X)__sync_fetch_and_sub(X, 1)
>
>
>
> On 13 Apr 2009, at 10:19, Eric Wasylishen wrote:
>
> Hi,
>> I ran in to a small problem when compiling GNUstep (svn trunk) on
>> Debian testing for PowerPC. GCC is "gcc (Debian 4.3.2-1.1) 4.3.2"
>>
>> Compiling file NSObject.m ...
>> /tmp/ccF8zgwE.s: Assembler messages:
>> /tmp/ccF8zgwE.s:730: Error: symbol `modified' is already defined
>> make[3]: *** [obj/NSObject.m.o] Error 1
>>
>> The PPC atomic increment and decrement functions starting at line 254
>> of NSObject.m both use the label 'modified:' in their asm code. I
>> found that by changing the labels in one of the functions to something
>> else ("modified2"), this error disappeared.
>>
>> I'm not sure if GCC is correct in reporting this as an error or not,
>> but it's easy to fix.
>> -Eric
>>
>>
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>>
>
>
Index: Source/NSObject.m
===
--- Source/NSObject.m (revision 28264)
+++ Source/NSObject.m (working copy)
@@ -218,7 +218,14 @@
#define GSAtomicIncrement(X) InterlockedIncrement((LONG volatile*)X)
#define GSAtomicDecrement(X) InterlockedDecrement((LONG volatile*)X)
+#elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)
+/* Use the GCC atomic operations with recent GCC versions */
+typedef int32_t volatile *gsatomic_t;
+#define GSATOMICREAD(X) (*(X))
+#define GSAtomicIncrement(X)__sync_fetch_and_add(X, 1)
+#define GSAtomicDecrement(X)__sync_fetch_and_sub(X, 1)
+
#elif defined(__linux__) && (defined(__i386__) || defined(__x86_64__))
/* Set up atomic read, increment and decrement for intel style linux
*/
@@ -256,11 +263,11 @@
{
int tmp;
__asm__ __volatile__ (
-"modified:"
+"incmodified:"
"lwarx %0,0,%1 \n"
"addic %0,%0,1 \n"
"stwcx. %0,0,%1 \n"
-"bne- modified \n"
+"bne- incmodified \n"
:"=&r" (tmp)
:"r" (X)
:"cc", "memory");
@@ -272,11 +279,11 @@
{
int tmp;
__asm__ __volatile__ (
-"modified:"
+"decmodified:"
"lwarx %0,0,%1 \n"
"addic %0,%0,-1 \n"
"stwcx. %0,0,%1 \n"
-"bne- modified \n"
+"bne- decmodified \n"
:"=&r" (tmp)
:"r" (X)
:"cc", "memory");
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
Ooops, this one is my fault.
Recent versions of GCC (and llvm-gcc / clang) support portable atomic
intrinsics. I've checked these on x86 and x86-64, and they generate
the same code that my inline asm uses. If you add this after the
Windows bit (it will probably work on Windows too, but I'm not
completely sure) then we will gain fast atomic operations on all
platforms (e.g. SPARC / ARM) that support them when compiling with a
recent compiler.
David
#elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)
/* Use the GCC atomic operations with recent GCC versions */
typedef int32_t volatile *gsatomic_t;
#define GSATOMICREAD(X) (*(X))
#define GSAtomicIncrement(X)__sync_fetch_and_add(X, 1)
#define GSAtomicDecrement(X)__sync_fetch_and_sub(X, 1)
On 13 Apr 2009, at 10:19, Eric Wasylishen wrote:
Hi,
I ran in to a small problem when compiling GNUstep (svn trunk) on
Debian testing for PowerPC. GCC is "gcc (Debian 4.3.2-1.1) 4.3.2"
Compiling file NSObject.m ...
/tmp/ccF8zgwE.s: Assembler messages:
/tmp/ccF8zgwE.s:730: Error: symbol `modified' is already defined
make[3]: *** [obj/NSObject.m.o] Error 1
The PPC atomic increment and decrement functions starting at line 254
of NSObject.m both use the label 'modified:' in their asm code. I
found that by changing the labels in one of the functions to something
else ("modified2"), this error disappeared.
I'm not sure if GCC is correct in reporting this as an error or not,
but it's easy to fix.
-Eric
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Small change in NSObject.m ASM needed for PowerPC build
Hi,
I ran in to a small problem when compiling GNUstep (svn trunk) on
Debian testing for PowerPC. GCC is "gcc (Debian 4.3.2-1.1) 4.3.2"
Compiling file NSObject.m ...
/tmp/ccF8zgwE.s: Assembler messages:
/tmp/ccF8zgwE.s:730: Error: symbol `modified' is already defined
make[3]: *** [obj/NSObject.m.o] Error 1
The PPC atomic increment and decrement functions starting at line 254
of NSObject.m both use the label 'modified:' in their asm code. I
found that by changing the labels in one of the functions to something
else ("modified2"), this error disappeared.
I'm not sure if GCC is correct in reporting this as an error or not,
but it's easy to fix.
-Eric
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
