>>QDSP-asm bugs

* Discovery:     5-9-1998
  Symptoms:      "MOVE X/Y/L:label" causes DSPword count error.
  Userlevel fix: Yes, by putting ">" or "<" in front of label.
  Diagnosis:     Error concerning handling of short or absolute addresses.
                 Probably located in MOVE-instruction handler or effective
                 address handler.
  Solution:      Force labels without ">" or "<" to behave as ">"
                 automaticly. Track down bug and replace old handler with
                 a fixed one.
  Fixed:         Yes, 12-9-1998, bug was in effective address handler.
                 Labels without short or long indication are forced to
                 long (">").

* Discovery:     5-2-1999
  Symptoms:      "MOVEP X:PP,..." causes the peripheral-address to be seen
                 as a value that out of range.
  Userlevel fix: Yes, by putting "<<" in front of the PP-address.
  Diagnosis:     A peripheral address is handled as an effective address and
                 hence can never get as big as $ff80 or higher.
  Solution:      If the address in the first field is equal to/higher than
                 $ffc0, the instruction must be handled as <<PP,... Will be
                 a pain in the ass probably.
  Fixed:         Yes, 17-2-1999, bug was in the expected place. Now, first
                 all, the handler tests for what value it has in the first
                 field. If not PP, then we jump to an existing other part
                 for handling EA -> PP types.

* Discovery:     5-2-1999
  Symptoms:      When "*" is used (i.e. the actual address) in instructions
                 over one word in size, they are set to a value beyond the
                 actual address.
  Userlevel fix: Well, there is a workaround.. You can put *-1, but this can
                 hardly be called an elegant solution.
  Diagnosis:     Upon writing to the second word in an instruction the
                 actual address is already increased by 1. This means an
                 incorrect number is written into this word.
  Solution:      The handling of this actual address must be done seperately
                 from the much used normal addresscounter. There must be an
                 addresscounter that always points to the beginning of a
                 block.
  Fixed:         Yes, 5-2-1999, bug was actually only in jclr/jset handling.
                 Luckily nowhere else. The bug was fixed simply by updating
                 the addresscounter after the address was written, not
                 before.

* Discovery:     17-3-1999
  Symptoms:      Labels defined twice aren't seen as errors. The last label is
                 taken. Not that serious, but ambiquity is nasty stuff.
  Userlevel fix: Nope.
  Diagnosis:     No checking is done when storing label-info to memory?
  Solution:      Find the routine responsible for storing label-info and add
                 checks to it.
  Fixed:         Yes, 17-3-1999, bug was indeed where it was expected to be.
                 There was already some checking implemented, but it wouldn't
                 work since there was no checking between the first and second
                 pass. Only in the first pass need it be done.

* Discovery:     17-3-1999
  Symptoms:      Labels like "r0_label" or "r3_label", etc. are handled
                 incorrectly.
  Userlevel fix: Don't use such labels.
  Diagnosis:     Probably a little bug in the operand-handling. Could also be
                 located in all kinds of routines for individual instructions.
  Solution:      Seek out if it is truly a problem with the operand-handling or
                 an error in all kinds of routines. Best done with using
                 multiple instructions to see if they can use these labels.
  Fixed:         Yes, 17-3-1999, bug was luckily only in the effective address
                 handler. If the label wasn't recognized, it was tested if it
                 could be Rn register. But if a "r?" occured in a label it was
                 immediately seen as a rn-addressingmode!

* Discovery:     17-3-1999
  Symptoms:      In the "rep" instruction, when you use immediate data, "<" has
                 to be forced. Otherwise the operand is seen as out-of-range.
  Userlevel fix: Use "<" in front of the value.
  Diagnosis:     Definitely to do with the handler of the rep-instruction. The
                 general effective address handler was fixed ages ago.
  Solution:      Seek out the rep-instruction-handler and modify to don't
                 expect "<".
  Fixed:         Yes, 17-3-1999, The solution proved right. But there was also
                 a problem with the 1st/2nd pass again. A value needn't be
                 processed and tested in the 1st pass, but it was.

* Discovery:     2-5-1999
  Symptoms:      movep p:..,.. gave an "invalid memory space" error.
  Userlevel fix: none
  Diagnosis:     Probably in movep handler. Otherwise in ea handler
                 (Probably not. Fixed that and checked over and over).
  Solution:      Seek out the movep-instruction-handler and modify to
                 handle <p:ea,..>. Add extra opcodes if required.
  Fixed:         Yes, 2-5-1999, the bug was in movep handling. Don't know
                 why, but only x and y were handled ok. The routine for p
                 was already there! Just not used (??)

* Discovery:     11-9-1999
  Symptoms:      IF, ELSE, etc seem to cause no ENDC or ENDIF to be found!
                 So complete rest of code is ignored!
  Userlevel fix: none
  Diagnosis:     Must probably be in IF, ELSE, ENDIF handlers.
  Solution:      Compare handlers to the ones in the first Qasm.
  Fixed:         Yes, 11-9-1999, Wasn't in handlers, but in handling order.
                 If a part of code was to be skipped, it still looked for
                 directives. Since the order was changed, it just ignored
                 all statements (including directives!!). 

* Discovery:     19-1-2000
  Symptoms:      When equates/labels are moved into x and y registers, the
                 uppermost byte contains crap.
  Userlevel fix: Mask out using &$ffff, but this is crappy because normal
                 sources won't work: HAS to be fixed!
  Diagnosis:     A consequence of how labels are stored. bits 16-31 are used
                 as a labeltype field to indicate x, y, p, l memorytypes or
                 an equatetype.
  Solution:      Use bits 24-31 instead of 16-31. Plenty of room and it will
                 work in any case.
  Fixed:         Yes, 19-1-2000, used bits 24-31, but had to perform quite
                 nasty for the labelstorage. It does seem to work and it
                 even improved the output of labels in LOD.

* Discovery:     23-1-2000
  Symptoms:      Y memory bset/bclr/bchg will be assembled as X memory one!
  Userlevel fix: none
  Diagnosis:     Probably some bug in the instruction specific code.
  Solution:      Check out the instruction handler and correct this bug.
  Fixed:         Yes, 23-1-2000, seems the work flawlessly now.

* Discovery:     29-1-2000
  Symptoms:      Comment following TCC instructions was misinterpreted.
  Userlevel fix: Removing comment.
  Diagnosis:     Maybe this bug Thomas was talking about, though I have
                 checked all opcodes before and everything worked. It is
                 quite possible that this instruction has it's own parallel
                 instruction handler.
  Solution:      Add ";" recognision to the specific parallel instruction-
                 handler.
  Fixed:         Yes, 29-1-2000, as thought there was a specific handler
                 that fucked up.

* Discovery:     19-8-2000
  Symptoms:      Use of faulty labelnames in statements is accepted and crap 
                 values are processed!
  Userlevel fix: Use the right label instead. (crappy solution)
  Diagnosis:     Check arithmetic parser for this.
  Solution:      -
  Fixed:         Not yet.

* Discovery:     20-10-2002
  Symptoms:      Equates in IF statements have wrong values.
  Userlevel fix: -
  Diagnosis:     Bugged IF statement handling? Or the memtype bits?
  Solution:      -
  Fixed:         Yes, 20-10-2002, was in 24-31 bits of value that is used
                 for labeltype (p,x,y,equate), these bits were fetched as
                 well!
