Wednesday 16 April 2014

The Final Countdown

So it's Wednesday the 16th of April. And for some reason we're still with snow. Quite an odd day, but one in which I will be posting what is likely my last mark-able blog post for SPO600. As much as I'd like to say it's going to be built, that is unlikely.

I've updated my previous rough draft code a bit, once I found my mistake with the random register values. For example, the atomic add now looks like:

           static __inline__ void atomic_add(int i, atomic_t *v)
           {
                     __asm__ __volatile__(
                                   SMP_LOCK “add  %1, %0, %0“
                                   :“=m” (v->counter)
                                   :"ir” (i), “m” (v->counter))    ; - this needs fixing/porting to proper aarch64
           }
    
No need to provide actual registers since their own code is just using whichever ones are available to them.

I've also manager to complete the port of subtract, subtract and test, increment, increment and test, decrement and decrement and test, which I've maybe inconveniently added below. It wasn't too much to change really. I just hope "=m" and "=qm" are still valid in aarch64 assembler, as I was not able to find replacements for them. The c-style comments are for blog readability and not actually in the code.

//subtract
static __inline__ void atomic_sub(int i, atomic_t *v)
{
    __asm__ __volatile__(
            SMP_LOCK “sub %2, %1“
            : “=m” (v->counter)
            :"ir” (i), “m” (v->counter));
}   
        
//Subtract and test
static __inline__ int atomic_sub_and_test(int i, atomic_t *v)
{
    unsigned char c;

    __asm__ __volatile__(
            SMP_LOCK “sub %2, %0; beq %1“
            :"=m” (v->counter), “=qm"(c)
            : “ir” (i), “m” (v->counter) : “memory”);
    return c;
}

//Increment
static __inline__ void atomic_inc(atomic_t *v)
{
    __asm__ __volatile(
           SMP_LOCK “add %0“
           :"=m” (v->counter)
           :"m” (v->counter));
}

//decrement
static __inline__ void atomic_dec(atomic_t *v)
{
            __asm__ __volatile__(
                    SMP_LOCK "sub %0"
                       :"=m" (v->counter)
                       :"m" (v->counter));
}

//Decrement and test
static __inline__ int atomic_dec_and_test(atomic_t *v)
{
        unsigned char c;

            __asm__ __volatile__(
                      SMP_LOCK "sub %0; beq %1"
                     :"=m" (v->counter), "=qm" (c)
                     :"m" (v->counter) : "memory");
        return c != 0;
}

//increment and test
static __inline__ int atomic_inc_and_test(atomic_t *v)
{
        unsigned char c;

            __asm__ __volatile__(
                     SMP_LOCK "add %0; beq %1"
                         :"=m" (v->counter), "=qm" (c)
                       :"m" (v->counter) : "memory");
        return c != 0;
}

//Check to see if addition results in negative

static __inline__ int atomic_add_negative(int i, atomic_t *v)
{
        unsigned char c;

        __asm__ __volatile__(
               SMP_LOCK "add %2,%0; bne %1"
                       :"=m" (v->counter), "=qm" (c)
                       :"ir" (i), "m" (v->counter) : "memory");
        return c;
}

What remains of the atomic.h is a mask clear and set, and I need to track down the proper aarch64 versions of  logical 'andl' as well as 'orl', which thanks to the ARM pdf file we grabbed ages ago for class, have made themselves evident. I am not sure if they even require a port, since the code comments say they are x86 specific, Better safe than sorry I say (and say only for this particular instance). 

It's also not immediately clear if exclusive OR rather than inclusive OR needs to be used, which is another issue, but I would think the comments would mentioned if it wasn't inclusive. Inclusive it is (and firing off an email to the devs just to be sure).

//Mask code:
#define atomic_clear_mask(mask, addr) \
__asm__ __volatile__(
SMP_LOCK "AND %0,%1" \
: : "r" (~(mask)),"m" (*addr) : "memory")

#define atomic_set_mask(mask, addr) \
__asm__ __volatile__(SMP_LOCK "ORR %0,%1" \
: : "r" (mask),"m" (*addr) : "memory")


So for the purposes of SPO600, I do believe that's about all she wrote.
Ported atomics.h code for aarch64, the other asm is in dependency files, which obviously I have no control over, but all of which have aarch64/noarch versions for arm64 either out in the wild or just not in yum repositories (i'm looking at you, fftw3), and that odd "you're missing these tools" problem when I try to run the ./autoregen.sh.

I will likely still continue to work on this package over the summer with the community on my own time, and fix any issues with my code, and perhaps even submit it. Sadly, that can't be taken into account for marking purposes, but moral victories have value too

For For The Win 3 or how I got fftw3 installed on qemu

So, as I mentioned in an early blog post, fftw3 is required for Rubberband to operate and install smoothly on Linux, but v3 does not exist on the yum repository. What is a person to do!?

Well, I went ahead and grabbed the aarch64 compatible rpm source from rpmfind (as well as the fftw3-libs long and single sources), and ftp'd the files into my directory on Ireland in both x86 and arm64.

So while I cannot definitively say "yes" to fftw3 working on arm64 at the moment (all of the files installed properly at the very least), all the issues with x86 are out of the way, and the one hanging thread of a dependency on arm64 is but a tar unpack/install away from also being as such. Again, I went to work porting code, since that seemed of more pressing interest to the sake of this blog/course.

Of course running /autoregen.sh still gives me this:
----------------------------------------------------------------------
Checking basic compilation tools ...

    pkg-config: found.
    autoconf: found.
    aclocal: found.
    automake: found.
    libtool: found.
    gettext: found.
You do not have autopoint correctly installed. You cannot build SooperLooper without this tool.

No matter how many times I've gone back and made sure those particular files/packages are installed on arm64.

The code is more important...

Saturday 12 April 2014

Code Snippet

Since I won't have much time after today, before Wednesday to get a lot of coding in (exams come first), I thought I'd at least post the bits of aarch64 assembler code that I've managed to template out on my machine.

It's not too much, and I think I might need to edit a line or two of it so far, but it's coming along. I guess this is like my rough draft:

#if defined(__aarch64__) || defined(__arm64__)

#ifndef __ARCH_AARCH64_ATOMIC__
#define __ARCH_AARCH64_ATOMIC__

#ifdef CONFIG_SMP
#define SMP_LOCK “lock ; ”
#else
#define SMP_LOCK "”
#endif

typedef struct {volatile int counter;} atomic_t;

#define ATOMIC_INIT(I) { (i) }

#define atomic_read(v)  ((v)->counter)

#define atomic_set(v,i)  (((v)->counter) = (i))

static __inline__ void atomic_add(int i, atomic_t *v)
{
    __asm__ __volatile__(
           SMP_LOCK “add  x1, x0, x0“
            :“=m” (v->counter)
            :"ir” (i), “m” (v->counter))    ; - this needs fixing/porting to proper aarch64
}   

static __inline__ void atomic_sub(int i, atomic_t *v)
{
    __asm__ __volatile__(
            SMP_LOCK “sub x2, x1“
            : “=m” (v->counter)
            :"ir” (i), “m” (v->counter));
}

Friday 11 April 2014

Looking before I leap

In the interest of getting anything done, as the communication has slowed between myself and the dev's, I'm going to attempt something outrageous, which is this.
I will at least begin transcribing the x86/i386 assembly code into an aarch64 version, without implementing it directly into the program itself, as this is still likely a bit far off in terms of viability.

First the atomic.h, and then down the rabbit hole I go for any other assembly relating to it, of which there is some).

More on this, with samples of code/the entirety of what I right to come.

Sunday 6 April 2014

March Roundup

So it seems that a dependency issue with sooperlooper may prevent it at the moment from being build-able on aarch64. Dammit fftw3, why do you and Rubberband have to have such a close relationship? It doesn't appear to exist in the yum repository, so I'll have to scrounge around for it somewhere else.

Anyways, soldiering on in spite of that issue. Still working out bugs in the x86 build, which the upstream team have been adding back into their own code repository. I guess even if I end up doing rather poorly in a course designed to produce working aarch64 code, I may end up helping get sooperlooper updated from its previous state to one that is slightly more up to date. Still hoping to jump itno the atomic.h (which, oddly enough is where mediatomb led me for month+) this time, no arm64 code and from the look of it, no fall backs either. Should be fun.

With any luck, Chris will allow me to have access to australia/ireland after the class ends so I can continue to work on the package, as I certainly wish to. Maybe even work on others if possible in my spare time (Who am I, and what have I done with the other me?)

Sooper [dooper] looper! draft

So I've picked Sooper looper to work with mainly because I a) got a response from a member of the community (the main developer I believe), and b)said developer (Jesse) has been quite helpful in helping me solve issues with building the x86 version. In this case, I had to rewrite a couple lines of code, both relating to the wxWidgets dependency package. Code examples below.

This particular error:
gui_app.cpp:308:18: error: invalid conversion from ‘const char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
if (_host == "127.0.0.1" && _never_spawn) {

Needed to altered ever so slightly to:

if (_host == wxT("127.0.0.1") && _never_spawn).

Then:
gui_app.cpp: In member function ‘virtual bool SooperLooperGui::GuiApp::
OnInit()’ :
gui_app.cpp:250:38: error: ‘SetAppDisplayName’ was not declared in this scope
SetAppDisplayName(wxT("SooperLooper"));
Needed to changed to:
 #if wxCHECK_VERSION(2,9,0)
 SetAppDisplayName(wxT("SooperLooper"));
#endif, simply because wXWidgets has new features that old versions do not support.

I went straight from contacting Jesse to trying to build, without a thorough look at the code, so it may be a disaster (again), but I'm going to find out quicker if it builds on arm64 now and jump to libmad if that is the case.

Friday 4 April 2014

A humorous aside

So we've seen that systemd spits out errors a lot, in our case, with the Foundation Model.
Well, it seems the spat that Chris mentioned today between Kernal devs and systemd devs has taken its next obvious step.

systemd developer susepended by tux's daddy himself, Linux Torvald.

Looks like it's put up or shut up time.

Just thought some might find this funny.