Ex Bibliotheca

The life and times of Zack Weinberg.

Sunday, 24 August 2003

# 6:50 AM

Biked all over town today getting groceries (at the Berkeley Farmers' Market) and various bits of kit which I needed in order to repair Shweta's keyboard, which got a couple of traces burnt out in a beverage spill. Split keyboards cost $60 and up, so it's worth a fair amount of trouble trying to track down things like conductive acrylic.

The repair process is mostly tedious. It takes about fifteen minutes to disassemble the keyboard to the point where I can get at the damaged traces, thanks to the ridiculous number of screws holding it together. Having done that, I then find the breaks and patch them over with the acrylic, wait for it to dry, then test them with a multimeter. The paint does not conduct well when wet. Unfortunately, "quick drying" seems to mean "half an hour." Then I put it all back together again (another fifteen minutes) and plug it into a computer and see if all the keys work. Of course, they didn't, so I get to do it all over again tomorrow morning.

Wednesday, 20 August 2003

# 3:45 AM

I have the complete works of Cats Laughing on two CDs. W00t.

Saturday, 16 August 2003

# 5:25 PM

you don't notice where your web site is hosted until it matters

I live in Berkeley, California. This web page is hosted on a server in New York City. Which means it was shut down along with the rest of New York City for the past two days. I'd like to apologize to the people who tried to send me email at my panix address and it didn't get through.

Here's a really wonderful set of photos of the blackout in Manhattan, taken by John Wehr of Memeufacture. (Link courtesy boingboing.)

And here's a classic op-ed rant by Greg Palast about how this was all caused by deregulation and corporate fraud. I'd like to hear from the other side of the argument, but I'm not finding one at present; suggestions appreciated.

Monday, 11 August 2003

# 6:40 PM

compiler author's advice to CPU designers

This arises out of a discussion a couple weeks back on the GCC mailing list and IRC channel, where we were talking about how there isn't much communication between GCC maintainers and CPU designers, as far as we can tell. We tend to get handed a finalized instruction set reference and told "make us a back end."

So forthwith what one compiler author (me) would like to say if he were included in early design discussions for a new CPU architecture:

Avoid dedicated, special purpose registers which are relevant to compiled code generation.
Examples of such include: the link and count registers on the PPC; the HI and LO multiply-result registers on the MIPS; the dedicated condition code register on almost all architectures designed prior to 1985; the stack pointer register on the 8086.
Classes of registers with a dedicated purpose, such as the predicate registers on the PPC and the Itanium or the floating-point registers on every architecture ever, are less awkward, but still not preferred.
It's okay to have special purpose registers that are not of direct interest to the compiler. For instance, control registers that will be manipulated only by the operating system are fine.
Yr hmbl crspdt cannot decide whether or not he likes the idea of having the program counter be a visible integer register (as is done on the ARM, for instance). On the one hand, it is convenient, in that it facilitates PC-relative addressing, eliminates the need for a special category of branch instructions, etc. On the other hand, it does consume one register. The same is true of the wired-to-zero register common on RISC architectures; it can be very convenient, but again it consumes a register.
Make the move instruction as general as possible. Especially, allow move from any register to any other register, move from any register to memory, and move from memory to any register. (How the assembly mnemonic is spelled is not important.) Allow use of all supported addressing modes in all moves to or from memory.
Do not expose internal implementation details in the instruction set. Examples of such exposure include branch delay slots, found on SPARC, MIPS, etc, and requirements to insert NOPs for correctness, found on old MIPS and now Itanium. I am personally of the opinion that windowed register sets (SPARC, Itanium) also fall into this category, but reasonable people may disagree.
Make immediate operand fields as wide as possible. This is especially important for register+offset addressing and relative branch destinations, but is also desirable for "load immediate" instructions and the like.
Don't leave out any primitives that you're just going to go back and add in revision 2. The most common instances of such are integer multiply and divide instructions, and atomic memory update instructions. Also, those atomic memory update instructions should be load-linked and store-conditional, not more limited primitives like test-and-set or load-and-zero.

Wednesday, 6 August 2003

# 6:55 PM

game review

Recently (pace this Slashdot article) an old PC-DOS game, Beneath a Steel Sky, was rereleased as freeware to run under the ScummVM emulator. So I gave it a try. BaSS is a 2D point-and-click adventure game of the style popular before there were first-person shooters or massively multiplayer online roleplaying games. LucasArts is perhaps the best known developer of such. They are not unlike text adventures with graphics. BaSS was done by a tiny British game house, Revolution Software, that I'd never heard of; I imagine they're hoping to draw attention to their current offerings by providing this one as freeware.

This sort of game is generally all about solving puzzles. The puzzles in BaSS are well thought out, not too easy yet possible to solve with the information available within the game - with one horrible exception, the second-to-last puzzle, which seemed completely unmotivated. I had to resort to an online hints site to figure out that one, and after reading the hints it still made no sense.

The game world is a fairly standard postapocalyptic cyberpunk city, surrounded by wasteland. The art is good for its time (not all that much can be done with two-dimensional prerendered frames in eight-bit color at 320x200 resolution) and the user interface is pretty smooth. The hero possesses a Highlander Trenchcoat (noun: a trenchcoat capable of holding an unlimited number of large bulky items in its inner pockets without displaying any visible bulge) so the inventory mechanism is utterly straightforward. There is lots and lots of game dialogue. Unfortunately, it suffers from a problem that Andrew Plotkin has complained about, which is common to this genre: dialogue menus aren't really interactive. To quote him:

...when you talk to a character, you get three to five choices of things to say. If you get a little farther into the conversation, you might get a submenu of four or five topics to ask about. And you know what? The right answer is always to ask about all of them. They're all important clues -- or important background information, or character-building, or some other carefully crafted message from the designers.
And that means each conversation is a cut scene. It is not interactive. I can't put it more clearly than that. You sit back and listen to the pre-scripted dialogue, occasionally clicking a menu option to hear the next paragraph. You could skip some options, or leave early, of course -- but why bother? You're just going to come back later and listen to the rest. It's the shallowest kind of interactivity.

I didn't mind it very much in this game, because all the dialogue is really interesting and fun to listen to. However, at one point I neglected to save for a long time, and then got killed, and had to run through the whole sequence again. And then it was tedious and annoying. This is another problem with the game: there are only a few points at which you can be killed, so you get lulled into a false sense of security. But the lethal points all give you no warning whatsoever. You're walking down a tunnel, and a giant spider pops out of a hole in the wall and eats you. Whoops. Hope you saved recently.

There was another problem with the dialogue: all the NPCs were far too willing to talk to the protagonist. The setup goes like this: the protagonist has been captured in the wasteland and brought to the city by its security forces. Their helicopter crashes, and the protagonist takes the opportunity to escape. Security goes on alert, everyone is told to watch out for the saboteur, and the inter-level elevators are disabled (getting them to work again is one of the major puzzles). Now the protagonist is walking around asking questions which clearly indicate he's new in town. Yet no one even for a moment suspects him of anything. They all tell him all sorts of crucial and sensitive information. Even the policemen themselves are like this! Needless to say, this seriously messed with my suspension of disbelief.

All in all, it was a fun game, but nothing wonderful.