TODO

TODO:

- BUG: numbers need fixed
  in hex, we can tell if a number is a byte (two hex digits) or a word (four
  hex digits); everything else should be disallowed.
  in hex, parsing a string like "ADC $02" is not ambiguous; the 2-digit value
  indicates that this is the version of ADC that operates on the zero page and
  takes a byte. similarly, "ADC $0002" is not ambiguous either; this is the
  absolute version of ADC which takes a word (2 bytes).
  but in decimal, we don't have these positions. "ADC 2" could mean either of
  the two. unless we introduce a special syntax to tell the different modes
  apart, this will be ambiguous.

  TEMPORARY SOLUTION: disallow decimal numbers, and make sure all hex values
  are either two or four hex digits.

- handle data
  - but (how) will this work bidirectionally? of course a disassembler usually
    tries to interpret everything as instructions, or signal that a byte is not
    a valid opcode, but this is not an error...
- handle unrecognized opcodes (i.e. raise an error)
  - only when assembling
- if there's only one version of an opcode, allow omitting the /mode
  - may be hard and may affect bidirectionality
- [currently in progress: parsing.pl]
  parse strings like "LDA #$01"
  - in the end, it should be possible to give Miu a list of "normally"
    formatted assembler instructions, and she will translate these to Prolog
    terms, then assemble
- [currently in progress: format.pl]
  conversely, translate terms like lda(0x01)/immediate to "LDA #$01"
- refactor

- documentation:
  - explain the Prolog-based format

- in opcodes that take a single byte, allow hi(Value) and lo(Value) (or
  similar) to use the high or low byte of a known value. e.g.

    Address = 0xC000,
    lda(hi(Address))/immediate,
    ...

- try again to do hilo/3 using CLPFD

- all of the stuff currently in miu.pl is basically the assembler code, which
  can go in a separate module. miu.pl can then be the main program that takes
  input (in various forms) and produces output.

- parsing of assembler syntax
  - since the DCGs are to be used unidirectionally anyway, they might as well
    handle any number of optional/required whitespace (as opposed to the
    current approach where "infix" whitespace is normalized to a single space,
    and then parsed as such)

- add formatting for labels and other constructs 

- start figuring out command line interface
  - and how to implement this in SWIPL