> here's an awkward one I've come across in QLTDis for QL Toady - and I've
> figured it out for myself, but I don't like the solution !
>
> ADDQ = 0101 ddd0 ssxx xxxx
> SUBQ = 0101 ddd1 ssxx xxxx
> Scc = 0101 cccc 11xx xxxx
>
> Where 'ddd' = data and ranges from '000' to '111'
> 'ss' = size and can be '00', '01' or '10'
> 'cccc' = condition code and ranges from '0000' to '1111'
> 'xxxxxx' = effective address = don't care and can be anything !
[Technically the xx xxxx is split into two: mm mnnn; the 'mmm' is the
addressing mode and the 'nnn' is the register number.]
As you notice (later), a size of '11' means Scc (but see below) as
opposed to ADDQ/SUBQ.
I don't know QLTDis, but you seem to have missed out:
DBcc = 0101 cccc 1100 1nnn
DBRA = 0101 0001 1100 1nnn
Where "nnn" is the data register number; DBRA is a synonym for DBF.
> I have a mask for ADDQ/SUBQ of 1111 0001 0000 0000 which gives 0101 0000
> 0000 0000 for ADDQ and gives 0101 0001 0000 0000 for SUBQ. Unfortunately, it
> also gives 0100 0000 0000 0000 (ie ADDQ) for some Scc instructions and 0100
> 0001 0000 0000 (SUBQ) for others ! (ADDQ/SUBQ are tested before Scc so we
> hit a result for ADDQ/SUBQ before testing for an Scc).
>
> So here is the problem - how to set up my masks and results to get Scc
> and/or ADDQ/SUBQ regardless of the order they are tested ?
>
> Simple solution, move Scc above ADDQ/SUBQ in the testing order. Can this be
> guaranteed?
Yes! If you are doing a single mask check for instructions, then the
order should be:
1111 0000 1111 1000 (0xF0F8) -> 0101 0000 1100 1000 (0x50C8) => DBcc
1111 0000 1100 0000 (0xF0C0) -> 0101 0000 1100 0000 (0x50C0) => Scc
1111 0001 0000 0000 (0xF100) -> 0101 0000 0000 0000 (0x5000) => ADDQ
1111 0001 0000 0000 (0xF100) -> 0101 0001 0000 0000 (0x5100) => SUBQ
The 'DBcc' replace the silly 'Scc An'; the 68k series only have 3 sizes
specified by 2 bits: 0 = .B, 1 = .W, 2 = .L, but with 2 bits there are 4
sizes possible, so size 3, which is non-existant, is replaced, in this
case, by 'Scc'.
So, DBcc is a subset of Scc which is a subset of ADDQ/SUBQ
> I've gone cross eyed trying to figure out all the options etc.
Don't forget that destination address modes 7:2 [d16(PC)], 7:3
[d8(PC,Rx.s)] and 7:4 (#data or SR/CCR) is illegal for ADDQ/SUBQ. (ie
mm mnnn cannot be in range 11 1010 [0x3A] - 11 1111 [0x3F]).
> I have noticed that the size bits in ADDQ/SUBQ are never '11' and are always
> '11' for Scc so I could use this I suppose,
That's how the processor spots the difference!
> but this effectively moves the
> ADDQ/SUBQ from type 18 to type 26 and is the same as moving the Scc test
> above ADDQ/SUBQ so I'm not fully convinced.
Don't understand type 18, type 26.
My first dis/assembler for the QL was the pseudoBASIC one by Alan Giles
in his "Quick QL Machine Language" book (from which I learnt 68k -
having previously learnt 6502 & Z80 it was easy to pick up). His
disassembler splits the instruction set up into functions for the first
nybble (4 bits) of each instruction. Thus the ADDQ/SUBQ/DBcc/Scc are
all handled by one function, 'dis5$()'
> Any offers ?
> All gratefully received - I've got spots in front of my (crossed) eyes now
> with all this binary stuff.
Try using hexadecimal (base 16) - it makes life much easier:
Take each set of 4 bits (binary digits) and convert to a number in range
0-15, then substitute A-F for 10-15.
I've used this above, using the C format of preceeding it by '0x' to
indicate a hex' number. My machine code monitor and assembler (from
Computer One) both require hex' numbers to be preceeded by a dollar ($).
eg 1110 1100 1001 0010 (converting each 4 bits) => 14 12 9 2 -> 0xEC92
or $EC92
Robert
