[f-cpu] Trying to clean up the ROP2 mess

[Michael Riepe <michael@stud.uni-hannover.de>]

Subject says it all. We need to make this more regular/orthogonal, and
more consistent with the way other instructions work. In particular,
we should provide operation variants that

    - work for 8/16/32/64 bit chunks
    - mask off the high bits / work on full registers
    - use direct/and/or mode

There should be the following variants (only `and' operation is shown):

    and.size        r3, r2, r1  // r1 = r2 & r3 & CHUNK_MASK
    sand.size       r3, r2, r1  // r1 = r2 & r3
    and.and.size    r3, r2, r1  // r1 = combine_and(CHUNK_SIZE, r2 & r3) & CHUNK_MASK
    sand.and.size   r3, r2, r1  // r1 = combine_and(CHUNK_SIZE, r2 & r3)
    and.or.size     r3, r2, r1  // r1 = combine_or(CHUNK_SIZE, r2 & r3) & CHUNK_MASK
    sand.or.size    r3, r2, r1  // r1 = combine_or(CHUNK_SIZE, r2 & r3)

and the immediate variants:

    andi.size       $simm9, r2, r1  // r1 = r2 & sign_ext(simm9) & CHUNK_MASK
    sandi.size      $simm9, r2, r1  // r1 = r2 & sdup(CHUNK_SIZE, sign_ext(simm9))

Operations with an `s-' (SIMD) prefix will work on full registers while
those without truncate the result to the chunk size. Due to the special
nature of logic operations, `sand.size' ignores the size flags. They do
matter, however, for `sand.and.size' and `sand.or.size' (indicating the
`combine chunk size') and for `sandi.size' (controlling the chunk size of
the immediate operand). For non-SIMD combine ops, the combine chunk size
matches the result chunk size (I see not much reason to separate them).

I will implement this encoding scheme in the next release of my
assembler/disassembler/emulator trio.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/