[erlang-questions] R12.0B and Sparcs
Fri Jan 4 13:51:17 CET 2008
If it helps I've done the following:
Untar the source of R11B-5 and R12B-0.
./configure --prefix=$HOME/local-`uname -m` > config.out 2>&1
in both directories.
gmake > make.log 2>&1
in both directories.
And then tared everything up and put them here:
Note, do to a brain glitch the config.out for 11B-5 was produced
on a fresh copy because I forgot to do it the first time and
the upload is soooo slow.
----- Message d'origine -----
De: "Bruce O'Neel" <>
Date: Thu, 03 Jan 2008 20:46:26 +0100
Sujet: Re: [erlang-questions] R12.0B and Sparcs
À: Mikael Pettersson <>
Cc: Jon Olsson <>,
>Thanks, but it's probably not worth spending hours on this. I suspect that
>the set of non-Ultra sparc users of erlang is quite small...
>Anyway, one of the many error messages is:
>/tmp//ccX10737.s:4437: Error: Architecture mismatch on "cas".
>/tmp//ccX10737.s:4437: (Requires v9|v9a|v9b; requested architecture is sparclite.)
>The line in R12B-0 that fails is:
>gcc -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -g -O3 -I/home/edoneel/tmp/otp_src_R12B-0/erts/sparc-unknown-openbsd4.2 -fomit-frame-pointer -Wall -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I../include -I../include/sparc-unknown-openbsd4.2 -I../include/internal -I../include/internal/sparc-unknown-openbsd4.2 -c common/ethread.c -o obj/sparc-unknown-openbsd4.2/opt/r/ethread.o
>As you pointed out, the code in erts/include/internal/sparc32 hasn't changed much,
>but, the R11 code had:
>around the files.
>When R11B-5 compiles the line that gets compiled is:
>gcc -MM -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -g -O3 -I/home/edoneel/tmp/otp_src_R11B-5/erts/sparc-unknown-openbsd4.2 -fomit-frame-pointer -Wall -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H
>-I../include -I../include/sparc-unknown-openbsd4.2 -I../include/internal -I../include/internal/sparc-unknown-openbsd4.2 common/ethread.c
>which looks quite similar.
>In both cases the configure request was:
>./configure --prefix=$HOME/local-`uname -m`
>I did several runs with turning on and of threads, smp, kernel-poll, and hipe.
>None made this go away, though, I did not try all possible combinations, rather
>I tried each one individually. 16 runs of configure would have been days...
>Would you like some bits of config.log or config.h? Also, the sparc
>version of OpenBSD is special in that gcc is 2.95.3 rather than some sort
>of gcc 3.x.
>Still, my email message was more so that if I ever needed to solve this again
>and didn't remember, google, with luck, would find it. Also potentially it helps
>the one other user of Sparc erlang :-)
>----- Message d'origine -----
>De: Mikael Pettersson <>
>Date: Wed, 2 Jan 2008 14:26:26 +0100
>Sujet: Re: [erlang-questions] R12.0B and Sparcs
>À: "Bruce O'Neel" <>
>Cc: , Jon Olsson <>
>>Bruce O'Neel writes:
>> > Happy New Year,
>> > Here at the home for ancient, disused, and discarded computers we noticed that
>> > while R11B-5 built and ran just fine on Sparcs, R12B-0 did not at least on
>> > OpenBSD and NetBSD.
>>What exactly is the failure? Compile-time warning from the assembler
>>on the V9 instructions? Runtime SIGILL?
>> > No, not Ultras, the sparcs that Sun hasn't actually shipped for 10+ years, the old
>> > V7 and V8 systems (ie SPARCstation 10s, 20s, 4s, and 5s etc).
>> > It turns out that a small change to
>> > erts/include/internal/ethread.h
>> > allows them to work again.
>> > 82a83,85
>> > > /* BEO for SPARC OpenBSD only. Not SPARC64! */
>> > > # define ETHR_DISABLE_NATIVE_IMP
>> > >
>> > Basically the above define throws away the optimized assembly code in
>> > erts/include/internal/sparc32 which is V9 (ie Ultra) specific.
>>The SPARC v9 (actually v8+) code referenced by ethread.h is
>>essentially the same in R11B-5 and R12B-0.
>>I suspect some configuration change is causing your problems.
>>- Did you build R11B-5 with SMP support on SPARC v7/v8?
>> If so, was it autoenabled or did you enable it explicitly.
>>- Does R12B-0 autoenable SMP on BSD/SPARC or do you enable
>> it explicitly?
>>GCC's __sparcv9 macro is unfortunately useless here
>>(it seems to be set if and only if 64-bit code is generated),
>>so to disable the v8+/v9 code automatically we'd have to add
>>a check in erts/configure.in and use that to #define a macro
>>which we then check in ethread.h.
>erlang-questions mailing list
More information about the erlang-questions