Older blog entries for ingvar (starting at number 108)

It is now finished and packaged. Though in some sort of confusion, it's not been properly tested, so a CLiki page will just have to wait.

License still needs to be hashed out. The assembler is mostly done (all the assembly parts are, SNA output nearly there, it needs better docs and some examples, I guess). I'm leaning towards an "implementor's guide" (I mean, as of "right now" it's actually lisp macross that expands into function calls that do some checking and eventually cause side-effects in a global variable that then gets mangled about by an assortment of code until it's done and then passed through and having one GF getting called on each object in the global list so as to hand back the bytes; then passed on to a GF that emits in the right file format).

It's actually quite cute, but I'm not entirely sure I understand how it works, unless I'm hacking on its innards.

Work is proceeding apace. I may be finished earlier than I expected. Now is left only "what license to use". I'm leaning towards either a BSD-style license or just leave it in the public domain. Both will, quite probably, cause comments.

Last implemented instruction generation was for PUSH.

The output and input frameworks are in place and tested. I've decided on a flexible output file format (basically, the method generating the output file is handed a stream and an array where all non-filled-in bytes are set as -1, so there's an option of skipping them past or defaulting them to some suitable value (the SNA file writer will end up emitting NOP for those).

Woohoo. I'm about half-way through the code generation for LD. One slight change of plans. instead of hard-coding the "result file generation" to be whatever-the-format-I'm-thinking-of, it will be suitably pluggable, either by switching a global or by passing a :format :<format&gt: to the assembly function (this, of course, means figuring out how to do proper filename mangling of the input name and generate a suitable outfile, either as two separate functions, with some sort of mechanism to select what should be called; at the moment, I'm leaning towards two EQL-specialized GFs, one for the name mangling and one for the file output).

The assembler now understands its input format and the "define instruction" macro (that defines a class, a macro and does some data manipulation) works, finally (nested back-quotes are scary but occasionally handy). The macro also does some compile-time data checking. Hmmm... Anyhow, we're now one step closer and "all" that's left is the rest.

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")

resulting in a suitably-named file foo.<ext> that can then be sucked into a Spectrum emulator.

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...