Older blog entries for ingvar (starting at number 103)

For all those who have asked today...

Yes, I am writing a Z80 assembler, the final plan is to have something eating suitably parenthesized assembler and emitting data files suitable for loading straight into Speccy emulators (I found at least one file format that was just what I wanted).

For those who feel encouraged to ask, when it is finished it will be ASDF-install able and somewhere on CLiki.

Estimated time of "being finished" is sometime after my wedding, until then assorted other things have (understandably) priority.

Added ADC, ADD, AND and BIT. Re-worked the class hierarchy to better fit what's actually in the Z80 instruction set, rather than what I remembered of it.

OK, have now found what looks to be a decent step forward in getting machine code out of symbolic representations (and data too, for that matter). Right now, it only returns the bytes in question, but it's nicely expandable with what (I think) I need. A generic function, EMIT, takes a "symbolic thing" and if the "thing" is a piece of data to dump (think "db", "dw" and the like) it is emitted as-is. If it's an instruction, it calls another gf, called EMIT-INSTRUCTION, with the "thing" and the symbolic instruction extracted. EMIT-INSTRUCTION is then EQL-specialized on the symbolic instruction with methods doing the Right Thing.

The symbolic things are, btw, constructed by macro-generated functions that (at the moment) only knows how to make things for a subset of the needed instructions, though I can see that I might have to add in some extra stuff describing arguments and variations (the only thing catered for right now is conditionalised functions, so that's "jp", "jr" and "call").

Erm, yes, hack in progress in a Z80 assembler engine. Do I hear giggling? THought so. It'll have one (and probably only) emitting format and taht's as one of the Spectrum emulator file formats (probably the "level loader", that should be taiolorable to do roughly what I want, I think). At some point, that'll let me hack some asm using emacs as my editor and generate output by something along the lines of:

(assemble "foo.asm")

OK, xlyb is now ASDF-packaged and the "run function on package load" (with ASDF) has been solved.

(defmethod asdf:perform :after ((optype asdf:load-op) (package asdf:system))
  (when (eql package (asdf:find-system "xlyb"))
    (funcall (find-symbol "XLYB-EXPORT" "XLYB"))
    (funcall (find-symbol "SHOW-WARNINGS" "XLYB"))))

Now, this has one obvious problem, it should, really, use an EQL specializer, but I feel somewhat wary doing that. I guess using LOAD-TIME-VALUE or equivalent would be OK, though.

Added bonus for figuring out why I use FIND-SYMBOL here...

Xlyb (the previously mentioned piece of code) is now even closer to done. Not close enough to be released to any but the closest mourners (hrm, is that an actual English idiom? anyway...), but close enough taht it should contain most stuff. I think I am missing cursors, right now. I am also missing all exported functions, but that is (as always) just some code away, since I can't be bothered going through the list of things to export myself. Hrm, I now wonder, is there a way of hooking in a "this function must be run on ASDF load-op-ing system blahonga"?

The piece of code mentioned on May 12th (persistence/restart layer for X11) is now mostly finished. Not tested or anything, but most of the code taht needs to be there is there. Thanks to the super-neat macro functionality of CL, most of the code looks like declarations.

"Ooops".

There are now two more CL-related mailing lists bouncing via home. They're (aptly, I'd say) named small-cl-src and small-cl-src-discuss. Mailman-run lists. I believe they're also on Gmane somewhere.

For those who want in on CL source mailing lists... Look here for small-cl-src and here for ...-discuss.

The former list is for source-and-source-only (currently size-limited to about 64 KB), post sources in-line, suitable for loading in one go. The latter is for discussions and is the Reply-To for the former. Don't like that policy? Tough, I do.

Now what have I embarked on?

Short history... There was an idle query on the "se-lispers" mailiing list, if there was any VM-based Common Lisp, since a VM-based Smalltalk environment could have extremely convenient stuff (like, say, teh ability to save all windows and then re-display them when the image is next restarted).

Consensus was "No, there isn't one" and I mumbled something along the lines of "but... well... one would get at least that functionality with a wrapper library..." so I am now heading down the route of writing an ugly hack to wrap around CLX so that one can save a core image and then (when the core is loaded) call a single function to restore all windows (taht, alas, means restoring all gcontexts, fonts, possibly pixmaps and screen and all sorts of fun & games).

It is slowly taking shape, I have written three macros to generate glue functions (one for functions creating/opening new windows/pixmaps/displays/screens/fonts; one for functions using them and one to wrap around return values (the latter is semi-ugly, since I have far less knowledge of what actually happens there)).

There is lisp coding in progress, this week's mini-project (started yesterday, hopefully releasable by Sunday) is a Game Of Life in CL, using CLX. The main difference from "normal GoL" is the displaying of three independent martices, one ed, one green and one blue (of course merging the colours where that makes sense) and what's needed right now is buttons to toggle what matrices to display, buttons to start/stop and possibly a button to single-step. Thankfully, CLX is a rather pleasant way of talking more-or-less raw Xlib, so...