Older blog entries for Michael (starting at number 19)

Misc

Lazy weekend. Spent yesterday getting new trainers and looking for knee pads, but failing to find any. Today I regretted not getting knee pads, as I'm buised all over after today's snowboarding lesson. Ouch. Now I'm off to grab a sandwich and go see Billy Elliot with my better half. Tired (though probably not as tired as adamd is at the moment...).

Upgraded my network card to 100 Mbit. Had to tell Kudzu to "F*ck off, I know better than ye!" The driver for the card that RedHat uses by default hangs our network - it drives the line constantly, something that is not good on an ethernet network :-) But by using the de4x5 driver rather than the default tulip one, and a bit of documentation reading, I was able to get it up and working.

LaTeX

Started work on the site. The html is at home, but I'll try and put it up on G141 at some point tomorrow. It's bare - submissions will be needed :-)

SWARM

Bah. Need to write documentation before putting it on the web. :-( Give me a day or so...

SWARM

Phew. Got my first coprocessor working in SWARM. I've started to implement an extended system coprocessor (in the ARM7TDMI system information is stored in an on-chip coprocessor). Now my applications can access a cycle counter by doing:

mrc 15, 0, r0, c11, c0, 0

This leaves the result in register 0. Question for the community now: I hacked up a C macro to let test applications in C directly access this like so:

#define rpcc() ({ uint32_t __t; __asm__ volatile\
 ("mrc 15, 0, %0, c11, c0, 0" : "=r" (__t) :);\
__t; })

Now, I found the __asm__ format by lots of looking at the NetBSD and Nemesis source code, same for the mrc operand formating. Can anyone suggest a source of documentation for either of these? I fed a few obvious searches into google, but to no avail.

Anyway, tomorrow I can profile that bit of ARM core I've had sitting about. I'll try and feed the changes up to freshmeat too.

hacking

Fixed some stuff in SWARM, expanded libc. It's quite cool - I've got enough of libc implemented that I can simply compile my test apps for SWARM these days without thinking about it. Of course, I look forward to the day's when I don't have to write bits of POSIX anymore (I worked on the POSIX/sockets later for Nemesis). Any hows, the coprocessor stuff is nearly there. If anyone knows stuff about instruction timings on the ARM, and knows why MCR is one cycle longer the MRC (see my posting on comp.sys.arm today) then let me know please!

Kid A

iain: Radiohead to me are tracks like Paranoid Android, The Bends, Planet Telex, etc. I prefer my Radiohead served live where it has much more spirit to it. The National Anthem live is quite gutsy. But, I really liked Climbing Up The Walls on OK Computer, and I think Kid A picks up on that kind of track. As much as I miss the more rock tracks, I can take Kid A in parallel. It's just another side of the coin. I can see that we're going to have to agree to disagree over this one :-)

LaTeX

Okay, I'll set up the LaTeX site over the weekend. I'll post here when it's up. I've just far too much to do during the week to fit it in. I think I'll make it a place for both styles and for cunning macros too. And anything else LaTeXy.

Work

Back in the dept today - decided that the work I was going to do at Xilinx was best started from here. All the tool flow that I need is here, and it would be more effort to run it there. I'll probably go back in a couple of weeks when I have some circuits that need to be done.

Toys

Decided I needed to finally get a LART, so I pop over to thinkgeek (where else?) to grab that green koosh gun they were touting on their banner adds for a while, but it's gone :-( Looks like I'll have to settle for a Net Splitfire instead. Will come in handy when I have to do some teaching next term ;-)

Kid A

Kid A, the latest Radiohead album is really good (I saw a mixed review earlier here). Really good sound, more mellow than previous outings. At first I really missed the usual gutsy Radiohead tracks (Airbag, Electioneering, Paranoid Android, My Iron Lung, Just, yada yada yada) but I got over it. Optismistic and The National Anthem are my faves (though I'm natoriously contrary about these things - it'll probably change in a day or so :-). If you'd not heard OK Computer then you probably wouldn't realise that this was the same band that brought you The Bends and Pablo Honey.

Latex

Ha, no takers on my LaTeX site then? I might knock it up anyway and see if the saying "build it and they will come" is true or not. Watch this space.

ErikLevy: More on 64 bit systems. Besides Nemesis, You might want to look at Opal done at U-dub, they have a paper on just what I hinted at yesterday: "Opal: A Single Address Space System for 64-Bit Architectures". In relation, I was chatting with a friend about this and he said that the original Alpha chips, despite using 64 bit addresses internally, only had 43 (or there abouts) address pins, as at the time they didn't think people were likely to use more than that outside the processor.

Community suggestion: I'm a big believer in seperating style and content - thus do my documenting in LaTeX. However an often cited complaint is that unless you really know LaTeX well, defining your own document styles is hard, so you're stuck with the default LaTeX styles, which can wear a bit thin after a while and makes it hard to create a doc that stands out from the crowd. My suggestion is that we need a themes.org for LaTeX, somewhere where people can upload and download LaTex style files. What do people think? We could even shove the arhive on g141.com - though I've not got the time to do anything as glitzy as themes.org :-)

ErikLevy: "A 32 bit based computer (hardware, kernel, software) has 4 GB's memory possible and a 64 bit one has 18 billion GBs. How many companies has needs of more than 4 gigs? "

AltaVista servers ;-) I'm sure that each one of the AltaVista back ends has (or at least had) 4 gig in them. It can also be useful to have a logical 64 bit address space - some OSs (for example Nemesis) use a single address space (which makes sharing of libraries and data easier than it is in a multiple virtual address space OS). Thus, though you're not physically ever going to use it, you logically might reach beyond 4 gig. Of course these are only virtual addresses that you'd want to translate to physical addresses (though Nemesis didn't implement this - we were interested in more the scheduling side of things).

Misc:

I start my internship at Xilinx tomorrow (at Edinburgh, Scotland). I'll be writing some bits of hardware for them which I can also use in my PhD, so we both get something out of it. I'm looking forward to the change of pace (though not the commute each day from Glasgow - it's two hours door to door, but it's only for a month or so).

Installed RedHat 6.2 on the new postgrad machine in our office and am in the process of mastering it (master is our nightly automated patch/update system - once a machine is mastered it gets updates automatically once they given to master). It's one of these things that I do so infreqently that despite having done loads of them I need to relearn it each time.

Snowboarding again - it rocks :-) I'm getting quite confident now - I can steer across the slope on both toe and heal edges, so I'm less of a danger to society :-)

Slow day. Technically a holiday.

Today I have been mainly hacking. As part of my PhD I'm looking for text applications to apply to my reconfigurable ARM I'm designing. A pretty one would by MP3 decoding. I saw MAD - MPEG Audio Decoder mentioned on the NetBSD-arm32 mailing list. This is an all fixed point implementaiton of an mpeg audio decoder, complete with ARM optimisations. Downloaded it and installed it on my sharc, and it runs fine, though I've not bothered to compare the performance with mpg123 yet.

Thus yet another goal to add to my list of things to do is to try and get MAD to run on SWARM. Problem is that it requires version 4 of the ARM architecture (ARM 7 and above) - and I thus far just implement most of version 3 (think ARM 6). So I'm adding the necessary ARMv4 instructions to SWARM along with the coprocessor gubbins - boy, is the next release going to have a few changes in it!

Problem is that I'm about to hit my Xilinx internship - so just as I'm beginning to look at the problem, along comes something to force me away from it. Doah.

Lull in diary entries (sorry adamd! ;-). Been worn out - between lack of sleep and snowboarding, I've been keeping myself to higher level work. Coding whilst tired generally leads to me scraping the original and reimplementing it ;-)

SWARM

Finally decided that I am adding a proper coprocessor interface to SWARM after all. Thankfully, having actually planned it out the bits will flow nicely about. I still have the problem that some of the data I want needs to be shared between different classes which aren't really related - I might get around this by having a pervasives array. If I'm going to have some globally available data, then I want it accessed through a well defined, clear interface.

Again, timing is an issue. SWARM is a single threaded piece of software, whereas a realy ARM has lots of things going on concurrently. Thus I have to spooge a finely concurrent system into a coursly sequential system - this leads to some problems, as you can imagine. Still, looks like with a bit of careful consideration it should all work out okay.

Going Retro

It's been a retro week. As my NetBSD test platform wasn't doing much, I decided to set up an xpilots server on it. I had my ass kicked today (thanks Dave! :-), and kicked ass too (you know who you are...). But I discovered that the xpilot client (on my P200 running RedHat 6.1) was getting quite jerky at times, and the load was silly. AFAICT, it was enlightenment that was the problem, as changing to FVWM2 fixed it. My best guess is that enlightenment is sucking in my keypresses to see if they're for it before passing them on to the xpilot client. But because I'm almost constantly pressing keys, this is causing enlightenment to do quite a bit of checking, and between it and redrawing the xpilot client, my system is straining. Could be wrong though - if anyone has any suggestions then let me know.

Anyway, to get more retro than xpilots, all this gave me an excuse to change window manager for the first time in about a year (quite a record for me). Now I'm using vtwm ;-) We'll see how long it lasts - but I quite like the clean look I have on my desktop now, makes a change from my enlightenment setup.

Earlier

Spent an hour getting my shark (an old prototype NC developed by Digital) into a more usable state. I use it mainly as a place to test out ARM code I'm writing - allows me to check that SWARM does what an ARM really does (it's not ideal as the shark is StrongARM based, but it's good enough for now). Anyways, due to time constraints I'd not set it up particularly well - I'd log in at the console, set the display to my workstation, and then fire off an xterm. I decided that this was a pain - I also had to set up DNS, mounting of file spaces, etc., so I decided to spend an hour getting it done. Now I can just use xon to access the shark, which I've positioned on my bookshelf on its end :-)

Now learning how interfacing of coprocessors really works in ARM systems - decided my initial attempt wasn't what I wanted. The real problem is that modelling a processor in software causes lots of trouble with global data (or so I'm finding). For example, I want to provide a coprocessor which provides information like cycle counts, cache performance, etc. - but this data is neatly kept hidden in the main processor code - so I need to open it all out. The data depandancy graph is somewhat complicated. Ah well.

Later

Some loon is grabbing the image from the G141 webcam just under ever four minutes. I didn't realise watching me work was that exciting, especially as the camera only updates every ten minutes :-)

Redoing my ProteanSWARM - it's much simpler now, my previous solution was way overengineered. I'll still have to hack up a full coprocessor interface at some point, but at the moment it's gone.

I keep meaning to hack up BSD packages for SWARM too. An i386 package already exists, but it's a bit out of date, and could do with better platform support.

Rants...

Read Jonathan's rant (diary entry 15/9/00) on full time contract working compared to freelancing. I can't help but feel that freelance isn't the solution to everything. If you're starting a large project then you want people who are going to be around for the duration, not freelancers who could possibly stroll away after a short while. Yes, in the short term freelance may seem a better deal financially, but companies (at least in our industry) will compensate for long term commitment with stock options (why do you think they make you wait for it to vest? :-). I agree that bonuses on top of a dull wage is a Bad Thing (tm) - but if that's your problem then shop around for a better offer. Given the current state of the tech industry job market there's no reason you shouldn't get the job package you want - you just need to look for it.

I guess largely it's down to what you want from a job. If you're in it for the money and like the opertunity to work on lots of different projects, then fine, go freelance. There's certainly enough work going. Personally I want something more challenging - a medium to long term project on which I can produce some significant result (I'm not saying significant to whom though :-), and I doubt I'm the only one.

Jonathan has been making polite inquires as to where my game code is. Bah (my rendering code) has taken a bit of a back seat at the moment, as I decided that I'd made a mistake in the overall class design, and it needs some restructuring. Unfortunatly I've not had the after-work energy to tackle it. Soon, I promise... My motivation for this project usually coincides with releases of Edge magazine - the new issue of which finally fell into my hands this morning. Perhaps some hacking will be done in the next week or so. Than Jonathan can write all the meta game code in his non-linenoise-as-syntax-but-uses-whitespace-for-scoping language :-)

Historical note: My office mate Matt "Cheese Boy" Holgate has finally decided to fix his air football/pinball game that's been sat on his desk in bits for the last three and a half months (see the final picture (17th) of me and Matt playing it on the G141 WebCam Archive to get the idea of what it is). The thing eats battries at a great rate, so Matt decided to add a power supply to it. That was in May, but today he's finally got round to making the case mods (the air in here now stinks of melting plastic) - perhaps he might even wire it up too :-)