Adventures in 64bit cleanup

I’ve been doing a bit of clean-up in linux/FOSS code for 64bit systems and it’s starting to scare me just how much crap filters into Linux distributions every now and then without anybody noticing it.

nss-mdns was today’s violator – the Multicast DNS NSSwitch module (Multicast DNS is sometimes better known as Bonjour or Avahi).

What’s particularly disturbing is that reading through the code reveals that the author suffered from the fatal “all the world is 32-bit” mindset when he wrote it.  I’m surprised nobody else picked up the unaligned access warnings flying up their console, then again, very few people use Itaniums or other 64-bit systems with strict alignment as a desktop system these days.

A small amount of hackery and fidgeting later, the error has gone away (yay!), and the bugfix was submitted.

The other fun fix was surpressing the unaligned access fix-up handler in parrot configuration tests so it could actually work out the correct pointer alignment size.  This little piece of magic is done by using prctl(). The fix was submitted here.

Pox Nora

Pox Nora was advertised repeatedly on a number of gaming comic websites some time ago.  I think I saw it on Penny Arcade.

I signed up, and never got around to trying it because the game client was a 50+MB Java WebStart app, and I didn’t have the patience at the time to wait for it to download.

I finally pulled down the newer standalone (install4j. blergh) client (which is also Java based) and waited for it to pull down the 100MBs of Pox Nora client so I could finally give it a try.

I must admit, it’s rather addictive.  It’s a rather fun blend of Magic: The Gathering style collection and battlegroup building, mixed with shades of Final Fantasy Tactics and other turn-based battle games.

We’ll see how long this keeps my attention anyway.

Games and Censorship

Oh god, the OFLC and the NSW Attourney-General’s office have opened a can of worms.

Given the latest sort of back and forth, EB Games is a serious violator of the NSW Classification laws for selling games that currently aren’t classified.

These games include titles such as:  World of Warcraft, Age of Conan, Guild Wars and Warhammer Online (all of which I’ve seen on the shelves of my local EB).  I even have evidence of having bought unclassified games from EB in the past – I have a copy of Master of Orion I, which was bundled with UFO Enemy Unknown – UFO was classified, but MOO wasn’t – in its original EB shrinkwrap with the old-style EB price sticker intact.

Anyway, most of us don’t view this as being a big deal.  It seems EBGames doesn’t realise it’s breaking/has broken the law.  The NSW Police seem to be quietly ignoring it along with every other crime they ignore.

Anyway, there is a point to this, other than screaming at how stupid this all is.

Henceforth, I will not be posting my opinions on import games unless I can find evidence of an OFLC classification.  Technically, it might be sufficient to classify as a public demonstration if I include screenshots or detailed information about the game, so let’s just not risk it.  Besides, the imports I bring in for myself are a tiny tiny fraction of the total games I play and I rarely mention them anyway.

And…  if anybody talks about mass complaining to the NSW police that EB and every other games retailer are selling unclassified games, I’d strongly recommend participating.  It would give all of the relevant parties something to seriously think about if, all of a sudden, every reseller of games and the publishers are all being hit with classification infringements…

ia64: Plan9, Compilers and ABIs

So, I have my second-hand HP vx2000 (Single-CPU Itanium2 workstation) running in my room.  (OK, this itself is a mistake – it’ll be moved into the home office once I get sick of the added head in my room).

For some bizare reason, I seem to have come up with the idea that trying to port Plan9 to it would be a good idea.

I’ve started studying the architecture and standard ABI documentation and I’m still trying to get my head around little details, but the whole thing seems pretty doable if I beat kencc into shape first.

The standard ABI register usage suggests a mixture of caller-save/callee-save conventions (some of the global registers are available as caller-save scratch) – this should only require minimal changes to kencc as it’s a case of teaching kencc to work out how many extra registers it thinks it needs for any given proc for optimal results, and allocating them dynamically via the appropriate mechanism, and then ignoring their save/restore on call/return.  That itself shouldn’t hurt kencc much (unlike on sparc32, etc, where you need to work almost exclusively in the callee-save model to get best results if you want to use register windows, and that’s fairly contrary to how kencc thinks and allocates registers), but will make context switching and debugging a bit more complicated.

Alternatively, we could just ignore register spill-fill and try to cram ourselves into the scratch registers only.  This would probably sit well with most plan9 developers.

Last (and equally insane option) is to meet minimum requirements for spill/fill (so EFI calls that allocate registers won’t kill us), but allocate all the registers and treat them as caller-save globals

This will make context saves even more expensive (saving 128 64-bit registers WILL suck), but is simple.

Anyway, this isn’t the really hard bit – as far as I can tell, the hard bit is fixing the 9 assembler/loader to produce good ia64 machine code and pick sensible optimisations.

At least I know I’m not imagining it…

I’ve recently had the displeasure of having to update the copy of WANPIPE that we ship with our product at work from the old stable 2.2 family to the beta 3.3 family in order to support their new Synchronous Serial adapter (The A14x family which is replacing the old S514x family).  We use these cards to support Frame Relay communications.  Frame Relay is still reasonably popular in Australia for private point to point communications, and, to be frank, our product with a supported Sangoma card and annual support probably still costs substantially less than the cheapest Cisco with 100mbit ethernet + sync serial for frame relay support and equivalent support.

So far I’m not  impressed with the A142 kit or drivers.

The kit itself is pretty shoddy.  Whilst the card is a nice small dual-layer card which will fit into a low-profile PCI slot (and even comes with the half-height edge-bracket), the cabling that comes with it is atrocious.  The card has a mini-centronics connector with screw-terminals which the Y cable attaches to  (A142 is a two port card, and is the smallest they offer now) and that itself is OK.  The dodgy comes in with the V.35 cable kit which attaches a V.35 to DB25  cable to the DB25-Y cable that you screw into the card.  The main problem being that both the DB25M on the V.35 cable and the DB25F on the Y cable have screw terminals – so you can’t secure the two to each other making it the weakest (and usually highest-tension because the Y cable is short and usually dangles off the back of the system) join in your V.35 cable run.

And then there were the drivers…  After spending a while chasing my own tail because my old 2.4.30 build tree had been damaged (but was still churning out valid modules, just without valid ksyms), I finally was able to get a build of the 3.3 modules that worked.

Then I had to slave out and accommodate the new user-space tools, changed configuration file layout for wanconfig (the WANPIPE stack configuration tool), all to discover that they’ve managed to break DLCI state indication in two places:  First of all, you used to be able to check IFF_RUNNING to find out if the DLCI was active or not, not anymore.  Secondly, the LIP layer (Sangoma’s own WAN stack) reports via dmesg transitions in card and DLCI state.  I did my usual FRAD power-down test to make sure it was even tracing DLCI failure correctly, and LIP didn’t even notice the DLCI had gone silent/failed until I turned the FRAD back on and it was in it’s resynchronising state.

At least I got an email back from Sangoma technical support confirming that they had indeed broken the support unintentionally, and it’ll be fixed next release.  Shame they didn’t mention when that would be.

C: The Preprocessor

Sometimes you just have to step that extra mile and do something completely dodgy.

The termios way for setting baudrates uses macros to represent the bitrate.  When you’re accepting a baudrate from the user, what’s the most sensible way to do it in C?

  1. Get the macro value directly from the user.
  2. Get the baudrate as a string, and then string compare to determine which baudrate you want, and set the flags appropriately.
  3. Get the baudrate as an integer, and then integer compare to determine which baudrate you want, and set the flags appropriately.

People answering 1 or 2 can hand in their C licenses.

So you’re doing integer comparisons, right?  Hey, we can use a switch/case statement for that, right?

So shortly we get:

switch (baudrate) {
case 50:
    baudflag = B50;
    break;
case 75:
    baudflag = B75;
    break;

… etc …

Surely there must be a better way?

Thanks to the C preprocessor, we have a slightly better option…

#define SPEEDMAP(x) case x: baudflag = B ## x; break;
switch (baudrate) {
SPEEDMAP(50);
SPEEDMAP(75);
SPEEDMAP(110);

…etc…

I wouldn’t get too carried away with solving stuff this way though…

Games Games Games: December Splurge

OK, Being December, and being time of Chrismas Sales and big releases, I have picked up a few more games than I normally would, and there’s also last month’s stuff which I didn’t get around to posting about…

Because I’m lazy (that’s why there hasn’t been a post in here for ages…) I’ll give the ultra quick reviews!

Guitar Hero: World Tour (PS3): Guitar Hero is finally back, after the lackluster Guitar Hero 3.  The new game mechanics make for some more interesting and challenging play, and the soundtrack is actually pretty good.  About 25% through career mode for Solo Guitar.  Drum kit is nice and sturdy, shame about the calibration (fortunately I have a USB-MIDI adapter so I was able to fix it up using the Drum Tuning Tools that Activision/RedOctane released).

Armored Core: For Answer (PS3): More of the same giant robots on ice skates action (*ahem*).  Plays like Armored Core 4, only with a more comprehensible story arc, and some better revised equipment.  Quad-Legs are king-of-the-hill for mobility again!  Banzai!  I still find myself playing this with my finger firmly pressed on the boost button all the time.

Grand Theft Auto 4 (PS3): I finally caved and bought it.  I’m glad that Rockstar didn’t go for another round of gang mentality after San Andreas.  Car controls are twitchy, but all in all, enjoyable so far.

Gears of War 2 (X360): More Gears of War.  If you’ve played and enjoyed the first, you’ll love the second.  ’nuff said.

Valkyria Chronicles (PS3): Simply brilliant from storyline to mission design and gameplay.  If I wasn’t half-stuck on a mission, I’d still be playing this non-stop.

Race Driver: GRID (PS3): High speed arcade racing.  Not bad, but not for realism junkies.  Couldn’t seem to get it comfortably configured to play with my steering wheel, but playing using a Controller is quite satisfying none the less.

Mirror’s Edge (PS3): This game was a real surprise for me – innovative gameplay in a first-person perspective – rather than being a shooter, we have ourselves a first person runner.  The controls make free-running plausable in the first person view, and with a bit of practice you easily find yourself running through the levels at full speed and seriously considering making attempts on the speed-run records.

So after all of that, my main recommendations are:  Valkyria Chronicles (PS3 Only) and Mirror’s Edge (PS3 and X360) – both are excellent games with a fresh take on their respective genres.

Episodes in Driving: The CBD

Thanks to Retro, I did some driving into and out of the CBD today.

The CBD remains the one place I still feel uneasy driving around because of all the nasty little one-way roads, and the propensity for the traffic to do utterly stupid things.

Today was no exception.

Because it’s impossible to street park in the city, we were en-route to a parking lot that we’d identified before starting our trip as open and affordable for a Sunday afternoon.  Apart from missing the first turn-off due to misreading the map, we circle around and come back on Sussex St, and we reach the block and entry for the car park to find some fully licensed turkey has pulled up across the driveway for the parking lot, isn’t moving, and doesn’t appear to have any thing impeding him from moving his car into a less inconvenient position.

I hate using my car’s horn, but that’s exactly what I did – I was stuck mostly merged into the left lane behind him so I could turn in to parking station (which he was blocking the entry to), there were a queue of cars behind me also trying to get into the car park…  What else was I supposed to do when the driver ahead obviously hadn’t even though about the situation around him before stopping.

Fortunately, the trip back out again had no complications.

Harrison Bergeron

Harrison Bergeron was a movie I saw many years ago before I left Canberra back in 2000.

It’s a rather unique movie of a dystopian future – the government has stepped in to render everybody average, ensuring a happy population. One particular young man, Harrison Bergeron, is too intelligent for the limiting devices to contain, so the government recruits him to work for them.

Strangely enough, this video rarely makes it onto the dystopian sci-fi lists, and never made it to DVD. Somebody posted a copy of it on Google Video (embedded below). It’s worth a watch.

Continue reading Harrison Bergeron