Brasstacks

Mostly to support my own development on multiple computers, I've moved my Common Lisp port of COMFY-6502 to github. I chose the name cl-comfy-6502 for the repository, although the "cl" prefix is a bit ugly. The current snapshot of COMFY-6502 .

Thanks to François-René Rideau ( fare ) for organizing last night's inaugural Monthly Boston Lisp Meeting (Note: future meetings will apparently happen on the fourth Monday of the month.) I'm surprised I haven't seen reports on Planet Lisp yet, but I had an enjoyable time. I certainly didn't meet everyone there, but did get to meet nyef (who showed off some of his fearless adventuring into bare-metal Lisp) and Brad Parker, got to see Kent Pitman in person, and a few other notables, as well as numerous ITA Lispers. Discussion was wide-ranging (I heard only a fraction of the multiple conversations going on), and some of the most interesting stuff to me was discussion about the background of Dylan and Lispers at Apple in the 1990s. There was at least one person taking pictures; I'm sure they'll pop up somewhere in the blogosphere. Looking forward to more great meetings in the future!

Even though it is hardly a finished product, I've posted a snapshot of my current CL conversion of COMFY-6502 Not that I expect a huge pent-up demand for the code, but it might be slightly more interesting than the output examples. Thanks to Henry Baker for allowing the release. The page also contains a link to the TODO file describing my next steps. (Most immediately, my attempt to include JMP elision was messy enough to convince me I need a different class to represent opcodes+arguments as a unit.)

After all the work to write a post showing off COMFY-6502's ability to reproduce the Red Book tone routine, I made a slight mistake in translation. The code I presented differed ever-so-slightly from the Red Book routine in the case where the Y-register reached zero.

As I've mentioned before, I've become intrigued by Baker's COMFY assembler, and have been working on porting it to Common Lisp, and making it a bit more powerful in the link stage. One metric to judge the success of this kind of "medium-level" language is how well it compiles compared to hand-written assembler code. For the 6502, there are a few examples of code created by wizards like Steve Wozniak, which you can find copies of around the web, the largest being the Apple II monitor, the Integer Basic interpreter, and some medium-sized ones like the Apple II 6502 step/trace, the mini-assembler, the floating-point "Wozpack," and the Sweet-16 virtual machine. This kind of code has a lot of quirks that make it hard to straight-forwardly translate: lots of shared "tail code", branches known by the programmer to always be taken (to save a precious extra byte consumed by an unconditional JMP), and the classic "fake RTS trick", pushing a...

I don't know what this says about Lispers' attitudes toward automated testing, or toward the RT test framework, but the commonly-distributed versions of the RT test framework did not pass their own self-tests. The apparent cause is that the introduction of a hash-table and tail-pointer in rt.lisp to efficiently find tests by name and insert new tests at the end of the test list were not matched by the updating of the rt-test.lisp to consistently construct the miniature mock-up test suite. This diff for rt-test.lisp , introduces code to dynamically rebind those variables. The patch, in addition to one putting the self-tests into a separate package, has been applied to the HEAD of the CVS repository for GNU CLISP . Note that changing the package changes the names of the tests themselves, which requires editing the expected output in the tests. Note how powerful and convenient the dynamic binding feature of Lisp (optional, as it should be, in Common Lisp) can be: while running...

As I alluded to in an earlier post, Symbolics Genera takes a slightly different approach to packages than most current environments (such as SLIME under Emacs). Part of that is because, unlike GNU Emacs today, the editor and all its intelligence is running inside the Lisp environment; another part is due to Genera supporting multiple dialects of Lisp, each slightly compatible with the other. One consequence is that Zmacs pays close attention to the "file attributes line" in your Lisp source files. (That's the line at the beginning of the file which contains the marker "-*-"). Other Lisp environments use a heuristic, like looking for the first IN-PACKAGE form. A chicken-and-egg problem arises when loading a file that expects to be read in a particular package. What if the package doesn't exist? Well, it isn't possible to use that package to read the file. But the package itself is defined in a file. For me this caused a bit of confusion, because i...

Having hacked on the COMFY code for a while in Emacs Lisp, I got the itch to move it over to my MacIvory, which has been waiting for real work to do. I've crafted some tests in the Emacs Lisp using elk-test (trying to add heirarchical suites-of-suites along the way), and wanted to port them to one of the Common Lisp test frameworks (I'm thinking of checking out Stefil, LIFT, and rt, which I've used briefly). While copying the files, I ran into a few issues. I couldn't figure out an automatic way to handle line-ending issues in the text files. I ended up locating the file on the Mac OS side in the file browser, Mouse-R clicking to Edit the file, then M-%, C-q [LINE key] [Return] C-q [Return] [Return] ! in Zmacs, then saving to a file on the Ivory file system. (I like the offer to create non-existent directories on a save.) There is probably a Copy File(s) command I could have used to move them en masse, and I should have been able to code up a quick conversion routine...

I've been working a bit with Baker's COMFY-6502 code; a few notes of what I have learned so far. First, a couple of tiny bugs in the genbrc ; the code miscounts the size of the branch instructions, meaning that (- l 2) should be a (+ l 2) and so on. I found it handy to enumerate each clause of the cond. Each clause handles a particular case, such as when the "lose" continuation can be reached by a short branch instruction, while the "win" continuation is far enough away to require an absolute jump. Second, genbrc , genbr , and compile all provide the address of the resulting "continuation" as the return value. This is perhaps clear when one traces out all the recursion, but it isn't explicitly mentioned. One interesting case is genbrc when the "win" and "lose" branch destinations are the same: one could simply emit an unconditional branch to that destination, and return the address of that branch but actually returning t...

I encountered Henry G. Baker's COMFY compiler a couple years ago. ( Baker's site contains a text article , a TeX format article, and an Emacs Lisp implementation . The ACM published the two articles COMFY theory and COMFY-65 ) COMFY is not a very high-level language, in the conventional sense, but is an attempt to provide a clean but simple set of control structures on top of conventional machine code. Baker calls it 'medium-level.' The resulting compiler is very small; its main task in life is to automate the generation of branch instructions, which is one of the tedious parts of tightly optimizing assembly programs. Yet it allows as well for arbitrary Lisp-style macros. I found the concept intriguing, but I found the article and the compiler code itself rather obscure. Part of the obscurity is the unconventional names for the 6502 operations, unconventional notation for the addressing modes, and decimal numbers for opcodes (because Emacs Lisp does not accept o...

Just sent off the Paypal payment for a MacIvory II system with 2.6 MW of memory. I'm hoping also to get a Symbolics keyboard, although Symbolics is apparently out of the ADB box that allows the keyboard to be used with the vintage Macs. It was a tough call whether to splurge for this or, for about twice the money, a new MacBook Pro. I'm hoping the Symbolics machine will be much more entertaining. My main idea of a project is to use the Lisp Machine as a Chaos FILE host, in order to allow development on the CADR simulator with a versioned file system, without having to simulate and learn ITS or TOPS-20.  To get that to work, I probably will need to do a little bit of investigation to understand how the Symbolics box gets configured to talk on the network, what Chaos packets look like on the Ethernet, how to get those to my Python/Lisp code on the modern machine, and, for data security what would be needed to talk to a CD-ROM drive on a remote computer, or to use a remote com...

My blogging has been much less frequent of late, mostly because of an unfortunate abundance of non-computer issues. Despite those, I believe I have made some progress in my Chaosnet-on-OpenMCL work, but I've switched most of my hobby-development to Python, mostly to get in touch with trends outside the Lisp Universe. My current main project circulates around ChaosNET emulation; the main thing going for Python here is a socket interface that is roughly compatible between UNIX-like and Windows operating systems. Lisp can support that as well, but not for my favorite and familiar implementations. (One thing I hope to try before I get through this is to get an asyncore-like framework set up in CLISP.) So far, I have implemented a `chaosd' process in Python that simulates multiple ChaosNET `ethers' in the form of localhost TCP streams (on Windows or UNIX-like) or UNIX-domain sockets (on UNIX-like); each stream corresponds to a subnet. The idea has manifold goals: Allow the...

Mark Probst has developed a Common Lisp API for Flickr and mentioned it on his blog .

Looking back on my previous post about multithreaded queues, and based on a little hacking I was able to do last night on my multithreaded-Lisp-user-mode-Chaos-client, and having read a bit more in the Little Book of Semaphores, (must stop typing 'sempahores'!), in particular the turnstile pattern, and the barbershop problem, there are a few other ways to slice the onion. A "waiting room", i.e., the privilege of blocking on the queue is exclusive. That actually makes a certain amount of sense when, for instance, Chaos packets are already sorted by the destination connection. Does it really make sense for multiple consumers to be concurrently transacting on a single connection? What would make sense, in a C10k kind of way, is rapidly generating server connections in response to RFCs, and handing these connections to waiting server threads. Or, if a connection is known to have independent incoming packets, or is deliberately recycled, connections can queue through a tur...

I saw a link on reddit the other day regarding some math-related videos, including a series of lectures by Don Knuth , including some on TeX internals. (One frustrating bit about the Web video is the blurriness of his terminal. Another is that he uses what is now a slightly-out-of-date version of TeX itself). He made a comment near the beginning of section 3, probably similar to things he has written, to the effect that in his education he had benefited both from reading badly-written programs, because they were evidence he could do better, and from well-written programs, because they were a pleasure to read. He then wondered aloud which category TeX is in, but that either way it was a win. I'm not at all sure myself. Perhaps TeX is a monument to the best that can be done in Pascal, and simultaneously a warning that it is the best that can be done in Pascal. I had a definite feeling during grad school, when I was learning LaTeX to write my thesis, and learning Lisp on the side,...

I wanted to store a link to Alastair Bridgewater's (a.k.a. nyef on IRC) SBCL-based LispOS notes . Nyef's most apparent distinguishing characteristic is an amazing willingness to hack low-level internals on Intel x86-based Lisp implementations. Given the claim that " The classic problem with the 'LispOS Project' is that a large portion of the early effort would involve low level hardware hacking ", nyef seems to be the ideal candidate for overcoming that problem. Also, just wanted to record a link to a vendor selling the remnants of the Interlisp environment. Seems like for something under US$3000, one can purchase a x86-Linux-compatible version of the Interlisp programming environment.