Re: VAX addressing modes

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

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