FFado 2.0~rc1 FTBFS on Sparc

Hi.

It's way more than just Atomic.h:

Trying to find the system triple: (cached) sparc64-unknown-linux-gnu
Doing a DEBUG build
Detected DIST_TARGET = i686

The whole build system doesn't know anything about SPARC at the moment. I have a SPARC64 Debian system available, if anybody (developer) is interested in getting a login, just ping me. It has no firewire port (Sun Fire V880), but if need be, I could probably add a PCI 1394 controller and my io14.

Find attached a first patch. It adds sparc(64) to the build system and provides a generic compare-and-swap operation, though not atomic. Since there are different sparc processor versions, we'd probably need to code different versions for sparc v8 and v9.

Don't know if the Linux kernel, the gcc or libc provides something like atomic_cas_32 (see http://forums.sun.com/thread.jspa?threadID=5085084) on Solaris.

JFTR: http://developers.sun.com/solaris/articles/atomic_sparc/

Poll: should we just mark FFADO-2.0 as unsupported on SPARC? The attached patch fixes the build issue, but I have no runtime testing at all.

Last remark: Debian on Sparc64 is a 64bits kernel with a 32bits userland, only few apps are compiled for 64bits. The attached patch defaults to 32bit output, supporting also builds for 64bits. Hopefully. ;)

patch adding sparc(64) targets and a non-atomic CAS

The foremost question is, do we really want to support each of debian's gazillion archs? Is there man-power to back that up? In the long run, I don't think it will be useful to add skin-deep support for archs that will bit-rot in no time. I wouldn't be surprised if firewire support was shaky from the kernel upwards with anything but the most common archs, which these days has really come to include only x86 and x86_64.

As to the problem at hand, an easy, but not entirely trouble-free, solution is to use the atomic builtins that gcc >= 4.1 has. Of course a check for the gcc version has to be added, but from there on it's easy sailing.

use gcc builtins for ultrasparc

I'd also opt for "amd64 and x86, nothing more". Other target architectures seem to vanish, and I guess the typical FFADO user won't neither have slow SparcStations? nor Sun Servers like my V880 (way too loud, to large).

Anyway, I've added a second patch, enabling gcc builtin atomics for sparc v9. That's sparc64, and afaik, these CPUs have been on the market for ages (so not a big restriction, probably comparable to 386 vs. Pentium, where v9 is the "Pentium").

Though we don't have manpower to support it, we could add this second patch. I claim there won't be a single person actually using it ;) As for "gcc >= 4.1 check": we just mention it in the README file. "On SPARC, you'd need gcc >= 4.1 to compile FFADO. This will only work for UltraSparc? (sun4u), SPARCv8 and earlier is not supported."

Remaining patch for libutil, now that the build system has been fixed.

The build system has been fixed in r1675. Now, support for atomic operations has to be added. I've attached a new patch to this ticket, atomic.patch.

Once applied, it gives a fallback to the gcc builtin atomic operation. This is sensible, it calls the corresponding hardware functions on each CPU type, so there's no need to provide handcrafted ASM code in ffado.

Since this patch doesn't affect the main FFADO targets amd64/i386/ppc, it's save to apply the patch. We don't lose anything, we just gain support for SPARC, hppa, ia64 and some other. I therefore changed the milestone to 2.0.

(In [1682]) Apply the atomic-patch also to the 2.0 branch.

Fixes #197.