A view to code... Hopefully

So, it would seem the libmad community is all but dead, the last release of the package itself being a decade ago. It seems to have plenty of assembly to work with, thoug that's from at best a cursory glance. i haven't tried to build it on x86 or arm64 yet. That will be today's task.

Sooperlooper has a more active community, in fact the dev got back to me rather quickly, but the news was  that "SooperLooper doesn't use any x86 specific code so it won't be the holdup. The 3rd party dependencies should be OK as well, as far as I know!"

I wasn't able to dig into the code too far, so I don't know if that means what it meant for mediatomb (aka this will build already), or if that means it should be pretty easy to work over and run on aarch64 with a few tweaks. Again, today.They both have the same amount of code in them, more or less, so it's going to be whichever I can dig into quickest, and since sooperlooper is still active, that may help a lot.

This is going to be an emergency landing, with a real bumpy ride getting there.

Swing and a miss - strikes left

First attempt at a different package from the list, got a hold of someone from the community, and the files that have the ASM aren't compiled, so there's no need to change the asm/port it to aarch64.
Well so much for that. Frysk is way too much to tackle in the amount of time left. Libmad and/or sooperlooper however look more promising, few files, not a lot of asm to switch over. Just need to hear back from either community, as sooperlooper doesn't build on x86 and that'll make aarch64 nearly impossible. (missing headers), and libmad seems to have died as a thing nearly a decade ago.

Still it's mostly atomics in Sooperlooper and some performance in libmad. Not too hard to at least port.
Still trekking forward. Much thanks to Chris for floating the goal posts on this one yesterday morning.

There are worse things than death..

And it turns out, having your package compile due to C-fall backs after you finally manage to get your aarch64 environment built is one of those things. Now I scramble to get another package from the list, and this time I'm contacting the community first, if only to see if there's anything I can conceivably work with in the short amount of time I have left.

I'm looking into Frysk, SooperLooper, and Ardour are all packages that are still free on the list that I'm looking into as quickly as I can. joining mailing lists and trying test builds on Ireland will be the quickest methods after doing a short prelim to grep for asm in the code.

Ugh... Not a good day.

Death of a Laptop

So Chris, taking some class time (this class must have been scheduled as a 'Intro To', only way to explain some of it) has solved at least a few of my issues, and a few from around the class.

It has become all too clear to me, Chris, and every one else in the room that this laptop is not capable of carrying on the heavy lifting. So I now have access to australia and can do aarch64 testing/work/etc on there, and can leave both Chris Markieta and Chris Tyler alone (so long as the Foundation model is installed on there already. I dont want to sftp a 13-16gb image file onto from anywhere unless it's over a cross over cable and i'm sitting at the machine itself.

So with that, today I will do my damndest to build mediatomb on arm64 and test the crap out of it. Well, in so far as I can get the dependencies installed. Oi.

I even got this hunk of junk to display on the monitors in class, albiet I had to actually look at the monitors on the wall to see what I was doing because the screen is too small to display to both properly. Oh and we found an ML language in one of the packages. To that student, I say goodluck.

And now something completely unemulated

So part of this weeks blog post is meant to deal with installing and running a different ARM64 emulator and testing the time and performance of our packages (at a point farther along than I am to be honest). And while 13gb's isn't something I normally throw around for just any file, but for the Foundation emulator I'll make an exception.

Everything went swimmingly, until of course, like all things in life, it no longer did. In this case the emulator ended up not running.

As I've never used this particular piece of software before, I have no idea why those devices aren't being found and the Foundation binary isn't being executed. I think I'll be firing off an email to Chris about this in the mean time unless someone, anyone other there in the wide world web can point to my stupidity and say "that's where you went wrong", which I would love at this point.

Assembler in aarch64

So it seems like the only actual code required to change is rather small. Thanks to Nick for giving me a hint in the right direction there. Would likely have rewritten the entire header file had he not. Forest for the trees. Leave the output/input/clobbering alone.

So yeah the first bit includes: __asm__ __volatile__ ("incl %0" - In essence, increment  "at->x" by one, discard the value currently in m, and replace it with the incremented value, and the cc just shows that the value is going to be clobbered/changed by the end of the function.

Increment register 0

In aarch64, this should simply be an 'ADD %0' or possibly 'inc %0'

The second line, as shown here:

decrement register 0, set byte e to one, otherwise zero

This one is a little more complex, but not too much really. It should be 'SUB %0,' since it's decrementing the at->x value, but I'm still looking for the an aarch64 variation on 'sete %1'. Shouldn't take too long really.
Inline assembly is a pain the in the butt to find specific answers for some time.

SPO600 Roadmap - Mediatomb, Lightspark, sanity

Who knew? I most definitely did not. After running into seemingly every possible problem with mediatomb I could, ./configure errors, make errors, I decided to leave it on the back burner for a day and try to get lightspark to build on x86, especially after Chris and I had talked about it for nearly an hour. Even worse. It seems the code is calling a header that is not up to date with where ffmpeg install certain header files, and I've yet to hear back from the dev team. That feeling in the pit of my stomach grows ever worse.

I've spent the past hour googling for various libav build dependencies (after the rather large list of dependencies from their own wiki requires google-fu). Searching 'fedora yum install <package name>' comes in REALLY handy for finding out actual package names when yum search fails on its own. Still, no luck libav causes headaches for a few other packages, but nothing helps my situation with lightspark any. Lovely. So hey, here's a thought, try medaitomb again. I mean, I can't feel any worse.

So I rebuild the configuration file. Yep, same old terminal output. Now to the usual fail of make... or so I thought! Somehow in the crazed state getting all the package dependencies for Lightspark, I managed to solve my mediatomb problem (me thinks ffmpeg was involved) and make ran! Not only did make uh make, but it also installed! I nearly jumped out of my chair. This excitement was tempered somewhat knowing I may have annoyed the crap out of the one developer involved with maintaining the code who I had been talking to and brought up the previous error with.

So to recap where I am:

mediatomb - works on x86 no problem (well, now). I'm going to continue talking with the community about what may be required for ARM64 implementation aside from converting/porting a few lines of x86 atomics to C or aarch64 assembly respectively. With a little more research into inline assembly, this shouldn't be too difficult a task to tackle and I look forward to jumping into the guts of the code vi editor in hand. I could have a test up by next week if all goes well.

As far as Lightspark goes, I've reached out to the community about both ARM64 and that make error that's preventing me from completing a successful build (and maintaining stress levels). But I'm unsure of where that sits. I've looked into another package or two, but I'll hold off a day or so and give the mailing list a change to get back to me. Another possibility has been brought to my attention from classmate Nick, that being the possibility of working on a more difficult package (a 2 on the scale), which Chris has apparently given tentative thumbs up to. If Lightspark falls through, I would gladly jump at such an opportunity to share in the pain that is Assembly coding and Linux package building.

--note --
I'll add in a picture or two of mediatomb in action/configuring or lightspark failing soon. 2am is too late to be swapping images around on this blog.