Yeah, they refer to it as "portable", but then go on to show that they haven't tested it on anything except x64 and ARM32; not only that, but it also depends on what you use to compile it (kbuild, GNU make, etc.).

That's not the case.

What you get depends only on the processor type.

What does vary is whether or not any given platform has actually been tested - i.e. the code compiled on that platform, and the test programme run.

Currently, only ARM32, MIPS32 and x64 platforms are available, and so the test programme has only been run on those platforms.

Finally, I think you may have been misled in the same way another reader further down was; note that the matrix is the matrix of toolchains which are supported out-of-the-box, i.e. where the library ships with build files for those platforms.

It is NOT the matrix of the ONLY tooclhains which can be used.

If two people misunderstand your homepage in the same way, it may be time to change your homepage.

Yes (and yes).

==

(Now done).

Interesting. Why did it turn you away? do you run code on many of the given platforms?

x86, yes, and the limitations on the toolchains you can use is weird and bad.

When you say "limitations", I'm not sure what you mean. I wonder if there's a misunderstanding here - the matrix describes the toolchains which are supported out-of-the-box, i.e. build files for them are provided, and they have all been tested and should work.

It's not a matrix of the ONLY platforms which CAN work. Is that what you're thinking? Other platforms might well need the porting abstraction layer to be implemented (the Intel compiler might offer a different set of atomic intrinsics, for example), but that's what it's there for.

It's not very clear, then. Reading the page leads me to believe that if x is my toolchain then y won't work, and the idea that such a thing could even be possible for your library speaks very poorly for it. I suggest tweaking it if this is not the case.

In any case, I did re-review the library today and I'll still pass on it because I'm very opinionated about C and this library doesn't match my opinions.

And I would like to see ARM64 support before I depend on this sort of thing, too, for what it's worth.

Well, to be fair! the page does say this immediately above the matrix - "The following toolchains and processors are supported out-of-the-box"

However, this is certainly not fully explanitative, and of course is just one line immediately above a large and eye-catching matrix.

I will change it, to make it more clear, and more eye-catching.

Regarding ARM64, it's something I want very much. I will finally have time for it now 7.1.0 is out. I Googled a bit just the other day and there are Pi-like ARM64 dev boards out there now, so I'm going to get one.

Which leaves me needing a SPARC dev board, and a POWERPC dev board, and an x86 dev board, and a MIPS64 dev board, and a... :-)

Wonder if you can use something like this:

http://elinux.org/Test_Lab_Architecture

to test on someone else's hardware?

I hope so.

I applied to the GCC compiler farm late last year, but received a reply only after so long a time that I'd deleted the key pair I'd submitted because I thought nothing was going to happen - and my efforts to get back in have yet been unanswered.

The GCC compile farm isn't for intensive testing or benchmarking, though (which is what you need for lock-free, to try to catch race conditions) - that test lab sounds more interesting.

I have to say though having your own dev boards which are yours and only yours and which you can hammer endlessly is very convenient. It's actually just occurred to me I can leave all the devs boards permanently running the test suite...

OTOH, I don't think I can get small, portable dev boards for all the platforms I care about, so at least for some architectures, a third-party farm is probably the only way.

Probably the most pressing requirement though is access to a Mac. Right now there are no build files for that platform.

By the way, the Pi3 had ARM64 cores.

I didn't know! thanks! I have a Pi 2 right now for ARM32, I'm completely happy with it.

There is no supported 64 bit kernel yet, though.

I guess they are using very specific machine instructions to achieve their ends.

Yes and no.

On Linux, the library uses the GCC atomic intrinsics. As such, the library funamentally supports any platform GCC supports with its atomic intrinsics. So the instructions are indeed machine specific, but they're provided by the compiler through a standard API.

Of course, actually getting something to work means actually compiling in on a given platform and seeing the test programme pass.

Thanks for the info. This is the first time a library has replied to me ;)

Google's huge investment in AI. You'll be hearing a lot more of it in the future :-)

("Do you REALLY want to use that API? I think you should space your comments out a bit more. Hey, your battery is getting low! BTW, I've just emailed your entire source base to Google for assimilation.")