On Tue, 8 Aug 2017, Mouse wrote:
At least I cannot find anything in the VAX Architecture Standard to
claim that CASEx is not just a slightly complicated variant of an
ordinary indexed PC-relative data load with the value retrieved added
to the PC as the destination register.
And what part of that does not apply equally to BRW? (Well, not
counting the "slightly complicated" part.)
The displacement used to calculate the new PC with BRB/BRW is a part of
the instruction itself, so it does go through the instruction fetch unit,
and consequently I$. I think JMP (or for that matter MOVAx) PC-relative
deferred would be a better analogy.
I see no reason for a jump table used with one of the CASEx
instructions to be treated specially by a disassembler.
I do, at least when the third operand is an inline constant: it's more
useful that way.
Hmm, given the hardwired placement of the jump table a CASEx with the
third argument using anything but the literal or immediate operand mode is
something that I find hard to imagine how it is supposed to be used in
practice, e.g.:
casel 4(%ap), 8(%ap), 12(%ap)
??? Perhaps a JIT compiler could have a use for it.
I know I, at least, find it more useful to see
1318: casel r0, $32, $4
131c: -> 1548
131e: -> 1607
1320: -> 1414
1322: -> 1414
1324: -> 1fc0
1326: movw $12, *(r5)+
1329: tstb r2
132b: blss 132d
than
1318: casel r0, $32, $4
131c: .word 022c
131e: .word 02eb
1320: .word 00f8
1322: .word 00f8
1324: .word 0ca4
1326: movw $12, *(r5)+
1329: tstb r2
132b: blss 132d
and _much_ more useful than
1318: casel r0, $32, $4
131c: movc5 $2, -07ff07fe(r11), $0, 0c(r4), *12(r0)
1328: tstb *(r5)+
Agreed.
Symbol table annotation would at least tell the tool the stream
requested is actually data, as well as where exactly the next
instruction starts,
Or it could, y'know, recognize the CASE instruction and do it
automatically. I don't see what's so undesirable about that.
Given how libopcodes is structured it may be tough to implement, and the
need to special-case it for literal/immediate operands only is a
counterargument IMO.
If you want to annotate the displacement table so that disassembly
starting partway through it can recognize that it's in a CASE table,
fine, but I don't see that as any different from annotating the second
and later bytes of any multi-byte instruction to deal with the
analogous situation there.
The advantage is it is consistent with the general instruction vs data
model and works with the tools we have at hand.
Maciej