Fred's Home Page

About me
csh is bad
Help out
KRoC/Linux (old)
occam upgrades
occam tutorial
Projects (PhD)
Quick gdb
UNIX crashcourse
WG / WGBuilder


(some people call these things blogs)

The last 8 entries are displayed on this page, older ones can be found here. An RSS feed is available here.


Another half-year plods by — as Douglas Adams said, "I love deadlines. I like the whooshing sound they make as they fly by.". Usual teaching high-load situation, but now heading into the summer lull. Seem to have written a lot of PHP and JavaScript to build some dynamic web "dashboard" stuff for the department, various useful analysis graphs and whatnot. As my colleagues remind me, yes, PHP has issues, but it does the job quick and clean (ish). Refactoring reduced to rewriting though. Kinda liking JQuery for eye-candy, though the way HTML behaves in different browsers is distinctly annoying; the issue of "onChange="..."" handling in the element, verses some more JQuery-specific stuff in a chunk of JavaScript. The long way usually works.

Decided it was time to embrace 64-bit computing some more, so bashed together a very limited 64-bit KRoC/Transputer-ish scheduler (in C) — heading towards 64-bit occam-pi like languages. Did a hand-written/allocated commstime benchmark in x86-64 assembly, and after getting through a handful of segfaults (gdb and valgrind ++), comes out with 16ns context-switch/communication time (unoptimised scheduler), and 5ns with -O2. That'll do for now! It's a bit optimistic for a general case since the channel output doesn't check for an ALTing input. On the other hand, the communication of 64-bit integers between the 4 processes is all done by calling "memcpy()", costing a function call regardless, so could probably do somewhat better known sizes. This is running on a 3.4GHz Core i7, with a run-time memory footprint (for the 4 processes) of around 576 bytes (has some holes in it) ‐ plus whatever stack the run-time and printf need, etc.


After upgrading my desktop to a 64-bit Linux a couple of months ago, finally got around to making the 32-bit chroot KRoC/occam-pi friendly, with GPU/CUDA support, and back to looking at some unfinished occam-pi things. One of these was making the "boids" simulation 3D. Scaling from 2D to 3D turned out to be surprisingly straightforward in terms of processes and whatnot. 3D boids

The rotation and rendering happens (serially) in the display process, but does not do any Z sorting/buffering as yet (hence why the obstacles occlude everything). All the 3D boid-ish calculations are done on the GPU (when using the GPU). With 2048 boids on my GTX-570 (also driving the desktop/display) it happily manages 50 FPS. In fact, it happily manages a little over 300 cycles-per-second if allowed to run at maximum rate. In this version (gpuboids15 derived) the boids and obstacles are just shared data, but the spatial grid is made up of processes; as well as the interactive obstacle. The run-time reports around 400 occam-pi processes. With 4096 boids, it manages a little under 200 cycles-per-second for standard "flocking" behaviour, down to 38 cycles-per-second for a parameter set that makes them blob together (and at that point, the cost of the interactions in a single location starts to get significant, due to the number of boids occupying the 3D space). The handling of the "per-location-visible-array" could also be smarter (at the moment, a fixed-size upper limit, which means a lot of GPU memory transfers potentially). With 16384 boids, 15 cycles/frames-per-second, and a GPU that quickly reaches 90 degrees..! 8k 3D boids Shown right are 8192 boids in a slightly larger grid (12x8x12) that produces pretty wavey effects (after turning up the vision radius a bit). That manages 60 cycles-per-second.

Next up will be moving the specific 3D calculation stuff over to the GPU (make it a per-boid thing) to take the load off the renderer, which can then focus on things like Z-sorting on the CPU (whilst the GPU gets on with the next cycle of the simuation).


Spent about 30 minutes staring at some AVR assembly dump (from gcc toolchain) wondering why the start of FLASH didn't look like an interrupt vector table. Turns out, yes, it really was missing, and the fact the device even executed (partially successfully!) the vector-less code it had in it was a surprise. Conclusion: -c is not the flag you are looking for (when trying to build a standalone binary blob for an AVR) — obvious.. That was less of a hastle than trying to find a means to program the device in the first place (having a shelf, and tube, full of ATmega8L-8 chips). I did have a crude ZIF-socket'd prototype board hooked up to the parallel-port (via a dissected cable from one of my old Iomega Zip drives, lost technologies for you) bit-banged from uisp. The last time I used it (probably 2-3 years ago at least) it worked. This time ran into some problems (1) no parallel port on the new desktop, and (2) when I did find a box with one of those legacy port things, didn't work anyway (after rmmod'ing ppdev, parport_pc and friends). Even after botching it with an ISP connector for Atmel's own programmer, still nothing; figured the reset pullup or other resistors floating around were upsetting it perhaps. Gave up on that, found a chipless Arduino Uno and used that — worked first time :-) [1]. I'll get around to installing bootloaders on all of these chips at some point to ease future programming grief! Then back to writing the code for it (in C) that I was trying to write in the first place.

[1] Well, programmed successfully — the missing vector table caused its own wierdness, as did the fact there was a 74HC04 hex inverter on the breadboard whose Vcc wasn't connected (that caused greater wierdness).


Today's gripe: people whining about performance from MATLAB and Java, when the source data is kept as human-readable text files containing floating-point numbers (or binary strings). Some more education is clearly required — i.e. get these people to implement the sscanf() behaviour for parsing floats, then see if they have the same opinions about why their program is running so slowly. What I find quite odd is the view that a 100 MiB text file containing nothing but comma-separated floats is useful for anything other than a computer; vim will happily open it, but not many other editors will cope so well.


Spent way too many hours chasing a bug in JavaScript that I hadn't expected, but on second thought, isn't completely unexpected. Simple(ish) scenario: AJAX wotsit returns a bunch of HTML with input fields and whatnot, along with a bunch of IDs that say what they're called. After bunging the HTML into the page, the JavaScript iterates over these fields and does the appropriate JQuery stuff to setup auto-completion, on-change, etc. And it all broke. Turns out that something like this:

    for (i=0; i<thing.length; i++) {
        $("#wotsit_" + thing[i]).change (function () { do_stuff (thing[i], document.getElementById ("wotsit_" + thing[i]).value); });

does not work in the way I expect. Perhaps I should have read up more on JavaScript's anonymous functions :-).. Basically it seems that the anonymous function is only created once, but in fact I really wanted thing.length of them. Hence, regardless of which one is invoked, they all get the last value of "thing[i]" and that particular element's value. So the lesson from that is that anonymous functions are generated based on syntax, not semantics. I.e., if "thing" had, say, 3 things in it, the above loop is not equivalent to its unwound form:

    $("#wotsit_" + thing[0]).change (function () { do_stuff (thing[0], document.getElementById ("wotsit_" + thing[0]).value); });
    $("#wotsit_" + thing[1]).change (function () { do_stuff (thing[1], document.getElementById ("wotsit_" + thing[1]).value); });
    $("#wotsit_" + thing[2]).change (function () { do_stuff (thing[2], document.getElementById ("wotsit_" + thing[2]).value); });

That wasn't obvious.. Solution: more grot, returning chunks of JavaScript (unwound loops) that are then evaluated in JavaScript.


Still ploughing through a multitude of emails (around 1400 now). Getting things together for CPA-2015, with a range of good and interesting papers :-). Minor interlude for a couple of days lacking hot-water after a series of small power-cuts (that left the UPS moderately unhappy, though better now, and the house alarm whining). Reluctant to call a qualified boiler engineer, spent some time poking around the boiler PCB with a multimeter (nothing obviously wrong) and trying to follow the fault-finding flowchart in the boiler service manual (impossible state reached) [footnote: such flowcharts should really be subject to some formalism in QA to ensure completeness!]. Descaled the secondary (hot-water) heat exchanger, that gobbled up a whole half-litre of 25% hydrochloric acid solution, still fizzing slightly — hot water flows much more happily again, but didn't cure the problem (symptom was no hot water and everything in the boiler looking okay, minus it actually firing up to give hot water; central-heating fine). Turns out (perhaps obviously) that the busted component was the hot-water temperature sensor probe (a thermistor), but not busted enough to trigger the "DHW temperature sensor broken" fault. Typical readings range from 15k-Ohm to 1.5k-Ohm, this one was reading about 300 Ohms. Disconnected we now have hot water \o/, a boiler whining about a broken sensor, and a replacement in the post (for less than 5 quid). Having studied the boiler PCB/wiring in some detail, if that ever needs replacing (unlikely, but 150-200 quid) might consider a home-brew/open-source boiler solution on an Arduino. The boiler hardware itself is fail-safe (in case the PCB fails in really strange ways, the boiler will spew hot water outside, rather than explode the central heating system).

In more (or less) serious things, decided it was about time to learn and embrace the whole JQuery, JQuery-UI, JavaScript, AJAX and JSON stuff. On one hand: wow, what a grotty hack that has grown out of all control and is generally abusing the web to do things web-browsers and servers were not originally intended to do. On the other hand, allows for the fairly easy creation of fancy web-based apps, so I'll let it off. And JavaScript, despite its ills, offers a fairly quick way for people to get into rudimentary coding (without requiring anything much more than a web-browser and a functional brain) which is also good — and the nice folk over at W3Schools have plenty of decent tutorials.


Apologies for any lack of communication on my part! I've got about 4" of exam questions to mark and an inbox with over 900 messages waiting to be dealt with. Things moving forward steadily however; for urgent things, repeated email prods may be the way to go (or give me a call).


Straight into the thick of it, oof. Mostly spending time preparing teaching for this term, and I have a lot! Also picked up an extra 20% role as "Undergraduate Director of Studies (QA)", that really does require some time put into it! (and a good excuse for some crude PHP hacking to build a coursework deadline co-ordination/planning thing — as a colleague said, an interface only a mother could love, but hey, it works! ;-)).

Managed to put a bit more time into Guppy and the EV3, heading closer towards my 4x dining-philosophers. The LEGO is built but untested, and I only just tested driving the motor from Guppy the other day, but that sort of worked (needs my Github version of Ralph Hempel's ev3dev-modules that has the /dev/ interface in it). At the moment it looks like this:

@include "guppy_stdlib.gpi"

@external "guppy" "define ev3_pwm_init () -> bool = 64"
@external "guppy" "define ev3_pwm_shutdown () = 64"
@external "guppy" "define ev3_pwm_on_fwd (val int motor, val int power) = 64"
@external "guppy" "define ev3_pwm_off (val int motor) = 64"

define test_g56 (chan(string) screen!)
  timer tim
  int t
  bool b
    screen ! "hello, EV3 world!\n"
    b = ev3_pwm_init ()
    if (b == false)
      screen ! "failed to initialise PWM device..\n"

    tim ? t
    ev3_pwm_on_fwd (0x01, 30)
    tim ? after (t + 300000)
    ev3_pwm_off (0x01)

    screen ! "done!\n"

    ev3_pwm_shutdown ()

Just back from visiting the Stella Maris Primary School in Folkestone, showing a group of year 4 children some LEGO robots and answering a lot of fairly inquisitive questions! Also met Stella the class gecko, which was a fairly placid but quite large creature.

Last modified: 2016-07-08 11:52:42.650855235 +0100 by Fred Barnes [ds] [plain]
Page generated: Fri Jul 08 11:52:43 2016
Valid XHTML 1.0! Valid CSS!