Author: bob

I was messing around with Java bytecode today for no particular reason. It’s a fairly simple assembly language — stack based so it takes a little getting used to but not hard for anyone who has used an HP calculator. I installed a copy of jasmin from my apt repository and got to work.

I wanted to make a “Hello, world!” that wasn’t completely obvious at first blush, so the plan of attack was to just push all the ascii codes on the stack in reverse order then call System.out.print() on them in a loop. Each iteration checks the loop count, if ok then pop the next code and print it. Here is where the bytecode verifier is a pain in the ass: apparently, the instructions must be executed each time through a loop with the same stacksize, or else you are branded an evil hacker. Very annoying. I could’ve used an array instead but that also takes a bunch of pushes and stores, so I just unrolled the loop. It works, I guess. Code after the jump.
Continue reading “Hello, java!”

It can be a humbling experience to revist old code. And I’m not talking about the dynamic simulation stuff, which is obviously a hack on top of a pile of hacks. No, this week I returned to my old pal ansiconv, the program that converts text files to images of the text file, rendering it as if you had ANSI.SYS loaded and typed TYPE KOOL.ANS at the cee colon backslash prompt. This program had achieved a modicum of success in its heyday but lately various alternatives have popped up written in languages such as C# and PHP. Being the C bigot that I am (one who writes Java for a living), I thought I would update this one great program, slap a PHP module interface on it, and unleash it upon the world.

Stylistically, the program was a mess: 2-space indentations, curly braces on the same line as the function definition, spaces (( after the )) parentheses, seemingly no rhyme or reason to naming of typedefs, and, horror of horrors, extensive use of studlyCaps. Oh, how I had strayed from the Unix flock. Even worse, I found an obvious bug in TAB character handling; a memleak or two in the error paths; infrequent to non-existent use of the static keyword; global variables aplenty, in one place documented “to ease calling into functions” (had I some phobia of struct?); and even a case of a function returning a pointer to a global variable. Take that ctime(3). All this in the space of some 2 KLOC.

The good news is, a few hours with vim and the codebase is much better: no more globals, no more leaks, no more uglyNamingConventions. I changed the build to create a library with a single entry point, which the ansiconv binary uses to work its magic. All the CGI support code was ripped out, and I wrote a small PHP module that utilizes libansiconv to do stuff on the web. Finally, I borrowed an enhancement from our friends who wrote the newer ansi converters, which is to emit 4 bits-per-pixel images when we can to reduce their size.

The other ansi converters are more full-featured, but C still wins in speed, hands down. A rough test shows ansiconv converts around 2500 ansis/minute, compared with 270 ansis/min for another popular PHP converter (both tests include the overhead of starting the PHP interpreter).

If you have no freakin clue what this post is on about, visit Doug’s great page, 16c.