This forum has been archived. Please start a new discussion on GitHub.

Ice-1.1.0 on (ultra)Sparc/Linux

For me, on two sparc-SMP (sun4u) Linux systems, Ice-1.1.0 seems to build and
run with no unanticipated changes. Only required changes seem to be related to the
fact that this is really an unexpected architecture/OS combination for Ice, so the
systems are sun-sparc-but-not-solaris. Specifically:

With changes as outlined in my patch from 7 March, and with a couple minor
modifications to include files (src/icecpp/config.h -- get WCHAR=4 for sparc-but-neither-Solaris-nor-suncompiler;
include/IceUtil/Config.h -- force ICE_32 because Sparc/Linux right now does not support 64-bit mode;
include/IceUtil/Shared.h -- force native atomic operations as described in the old patch);

And with additions to config/Make.rules.Linux to provide correct optimization
flags for gcc/sparc, Ice-1.1.0 compiles fine and passes all tests consistently
including the Glacier starter test which was not consistent previously.

Systems tested:
  • Ultra2-SMP 2x400MHz, identified as

    Linux 2.4.20-sparc-r0 #3 SMP Fri Jan 3 15:56:09 UTC 2003 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux
  • Ultra60-SMP 2x450MHz, identified as

    Linux 2.4.21 #1 SMP Thu Jul 17 20:39:05 UTC 2003 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux

Next is to get them talking to each other with Ice, but I haven't done that yet.
So far, though, looks very nice.


  • marc
    marc Florida
    Great news!

    After your interoperability tests, can you send us the patches? We can then include them into the next version of Ice.
    • These two systems talk to each other fine now, at least
      with Ice using the Ice/throughput demo with the clients'
      config files modified to look for other hosts for the server.
      (That is, I start the server on one system, then start lots of
      clients on both of them, and everything goes fine);
    • I am in the unusual situation that all of my systems
      are sparc/Linux, so I can't try sparc<->something-else very
      easily. I will try the build on a sparc20-SMP, though,
      which will test the architecture-has-no-atomic-mutex
      case (have to use MUTEX_SHARED). It'll take me a
      couple days to get around to this test.
    • I'll post the patches in a few days. It'll take me a little
      time to convert them into something that applies automatically
      to the source. On the other hand, we are talking about the
      New source file already posted in my original patch (the
      little C program in src/IceUtil for atomic operations) plus
      about 20 or 30 extra lines of code, so this shouldn't be a
      big deal.
  • Attached patch when applied to Ice-1.1.0 results in a source tree which builds
    and runs on Linux/sparc for sparc=sun4[c,m] and sparc64=sun4u. It always forces
    ICE_32 because Linux/sparc does not officially support 64-bit user mode yet.

    I cannot verify that the resulting source still builds and runs on anything but Linux/sparc,
    because I don't have any such things to test it on. So, this code is useful for a very
    small minority of systems ZeroC is interested in. ;)

    Still, Ice as built with these modifications passes all tests on two different sun4u systems
    and on one sun4m system. (U2-SMP, U60-SMP, SS20-SMP). So, as far as I can tell,
    this is what Marc asked for.

  • bernard
    bernard Jupiter, FL
    Hi Ferris,

    Thanks for this patch. I am integrating it to our Ice 1.1 patch branch ... although we can't test it, we'll try not to break it.

    I have 2 questions:
    • What is the license for the new IceAtomic.c? Without a suitable license, we can't include it in Ice.
    • We're trying to be consistent with macro names, e.g. use consistently __linux, not sometimes __linux and sometimes __linux__ (see the table below; maybe it should be included somewhere in the Ice distribution). In your patch you used __linux__ and __sparc__; is this because __linux and/or __sparc are not defined on Linux/SPARC?
    Macro                     Meaning                     Notes
    _WIN32                    Windows                     Even defined on Windows 64 bits!  
    _WIN64                    Windows 64 bits   
    __linux                   Linux   
    __sun                     Solaris   
    _WIN32 and _M_IX86        Windows on x86  
    _WIN32 and _M_IA64        Windows on IA64  
    __linux and __i386        Linux on x86  
    __linux and __x86_64      Linux on AMD Opteron 
                              (64 bit mode)   
    __sun and __i386          Solaris on x86  
    __sun and __sparc         Solaris on SPARC  
    __sun and __sparcv9       Solaris on SPARC in 
                              64 bit mode  
    _MSC_VER                  Visual C++                  1200 for VC++ 6.0, 1300 for VC++7.0 
                                                          (.NET), 1310 for VC++7.1 (.NET 2003) 
    __GNUC__                  GCC                         2 for GCC 2.x, 3 for GCC 3.x 
    __SUNPRO_CC               Sun C++                     0x540 for Sun C++ 5.4  
    __INTEL_COMPILER          Intel C++                   700 for Intel C++ 7.0  
  • Bernard, thanks for the response. Here's the information you asked for:
    1. So far as the actual source file IceAtomic.c goes, I wrote it, and so far as I am concerned anyone can have it. However, the 8 lines of assembly for __atomic_add,
      __atomic_sub are taken from the linux kernel routine
      linux/arch/sparc64/lib/atomic.S and anyone using IceAtomic.c would (or could)
      already have that on his system.

      So far as I know, the exchange_add part is "new" (for what it's worth), but in each
      case we are talking about how to wrap the "cas" ("compare-and-swap") instruction.

      Bottom line: I appropriated some linux kernel code for use directly by Ice on linux
      because I had to look at the kernel to see how to do the atomic operations for sparc64, and once you see how, there isn't any other way to do them.

      By publishing this as part of a proposed patch (enhancement) for Ice to the Ice community as a whole (i.e., on this and on other Ice forums), I intentionally
      relinquished any derivative rights I might ever have acquired. But the code is a derivative work of the linux kernel itself, I suppose, since that's where I found most of it.
    2. The compiler is just GNU/gcc-3.2.3 running on a sparc linux system. Relevant for Ice,
      it defines:
      • __linux__
      • __linux
      • __sparc__
      • __sparc_v9__ (or not, depending on compiler flag, but this matters only for what
        instructions are available. E.g., the "cas" of the first item is not available without the
        compiler flag '-mcpu=ultrasparc' (equivalently, '-mcpu=v9').)
      I used '__linux__' because a long time ago the compiler did not define all variations,
      and for symmetry with '__sparc__' (gcc doesn't define '__sparc', nor does it define
      '__sun.' For what it's worth, older versions of gcc do define '__sparc' and
      '__sun'; at least they do on Solaris.).

      Here's everything the compiler defines:

      ferris@lacewing:SIM/Simula/GROCER [294]% g++ -c -v -mcpu=ultrasparc
      Reading specs from /usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/specs
      Configured with: /var/tmp/portage/gcc-3.2.3-r1/work/gcc-3.2.3/configure
      --prefix=/usr --bindir=/usr/sparc-unknown-linux-gnu/gcc-bin/3.2 --includedir=/usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/include
      --datadir=/usr/share/gcc-data/sparc-unknown-linux-gnu/3.2 --mandir=/usr/share/gcc-data/sparc-unknown-linux-gnu/3.2/man --infodir=/usr/share/gcc-data/sparc-unknown-linux-gnu/3.2/info --enable-shared --host=sparc-unknown-linux-gnu --target=sparc-unknown-linux-gnu --with-system-zlib --enable-languages=c,c++,ada,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext
      Thread model: posix
      gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)
      /usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/cc1plus -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__sparc__ -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__sparc__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=unix -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE -D__sparc_v9__ -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc -D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -quiet -dumpbase -mcpu=ultrasparc -version -o /tmp/ccpb8AbJ.s
      GNU CPP version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice) (cpplib) (sparc GNU/Linux with ELF)
      GNU C++ version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice) (sparc-unknown-linux-gnu)
      compiled by GNU C version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice).
      #include "..." search starts here:
      #include <...> search starts here:
      End of search list.
      /usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/../../../../sparc-unknown-linux-gnu/bin/as -V -Qy -s -Av9a -relax -o c.o /tmp/ccpb8AbJ.s
      GNU assembler version (sparc-unknown-linux-gnu) using BFD version 20030515


      So, '__linux' is defined, but '__sparc' isn't, and I knew that gcc always defines the
      '__xxx__' forms, no matter what else. I didn't know off hand if gcc defined '__linux',
      and I didn't bother to check. Changing '__linux__' -> '__linux' is OK, but you're stuck
      with '__sparc__'

    Hope this helps.