This file describes the differences between the Motorola documentation 
and their mask sets as well as between their free assembler and tas
as of 12 May 1998.

1) Motorola docs say that the first thing in a program must be the following
   directive, which sets the TPU memulation memory size:
   
   %type tpu1, [256|512].
  
   However, neither of their masks contain such directive.
   The workaround is that you can specify it on the command line, with
   the -M option.
   
  
2) Motorola docs say that each channel subinstruction must start with the 
   'chan' keyword and arithmetical unit subinstructions must start with
   the 'au' keyword. Yet, their mask sets do not conform to that.
   Therefore, tas accepts the 'chan', 'au' and 'ram' keywords but does 
   not require them.
   
3) Motorola states that in the %entry directive the hsr0 and hsr1 conditions
   must be given and can not be set to x. In the G maskset they do not
   always give them. Therefore, tas will accept %entry-s without hsr 
   specified, however, it does not accept hsr to be set to x.
   
4) Motorola docs say that the read_mer keyword should follow and au
   expression, however, in the mask sets there are read_mer -s either
   alone or before the expression. Tas accepts au subinsn fields in 
   any order and does not require an expression to be present.

5) In pma_pmm.uc(149) they use the magic immed_1 keyword which is not 
   defined in any documentation. It means a 1, but forces the usage of
   immediate constant load rather than other methods. I did not hack
   it into the assembler. You have to edit the file and change immed_1
   to #1, which will have the same effect.
   
   To achieve this and 4) tas delays arithmetical subinstruction field 
   evaluation until the end of the subinstruction, then it tries to
   arrange an acceptable combination. If it has a choice, it will use
   a format 5 microinstruction for arithmetical operations, if it can't,
   it tries format 1 or format 2 (these two are identical from the AU's 
   point of view).
   
6) Motorola does not differentiate between lower case and upper case letters.
   I do not like this at all, but since they rely on that in their
   mask sets, tas does not differentiate between them either, with one 
   notable exception: include filenames are not converted.
   This has a side effect that you have to edit itc.uc(89) and spwm.uc(81)
   and change the include file's extension from .UC to .uc.
   
7) Motorola states that fields in a subinstruction are separated by commas 
   and subinstructions within an instruction are separated by semicolons
   while instructions or directives are terminated by full stop.
   Apparently they do not always follow this tradition, in qdec.uc(232) and
   qdec.uc(248) they use ; for field separation ( ;ccl ) and in psp.uc(90) 
   they have an interesting "hsr0=0,." construct. Tas does not allow such 
   sloppyness and you have to edit these files to compile them.
   
8) Motorola docs say that there are two unused bits in each entry descriptor 
   which must be set to 0. However, their assembler sets the bits to 00 if 
   you had parameter preload specifications in your %entry, sets them to
   11 if you hadn't. I do not know if it makes any difference, but tas 
   sets them accordingly (and against the docs).
   
9) Tas does not paginate the listfile (not yet anyway) and therefore it 
   accepts but ignores the %page directive. As a consequence, don't look 
   for page headers in the listfile :-)
   
10) Tas does not generate crossreference tables, symbol tables or 
   debugging info files. This means that you can't use it with the 
   Motorola debugger. I have no idea (nor docs) about the format of their
   debug files. 

11) Tas can generate a C include-able file which contains the microcode 
   memory contents. It is basically 256 or 512 longwords in the format 
   so that you can write in your C code:
   
   const long tpu_code[] = {
   #include "tpu_code_file_generated_by_tas"
   };
   
   and then your program can copy it to the TPU RAM during init.
   I thought it might be useful.
   
12) Tas can read from the stdin and write to the stdout, which under unix 
   is considered to be a Good Thing :-) In addition, it supports include 
   path specifications, which, again, is a Good Thing.
   
