Re: VAX addressing modes

[Johnny Billquist <bqt%update.uu.se@localhost>]

(Sorry for the top-post)

For what it's worth, I agree with Mouse. It is silly that a disassembler 
sees a variable length instruction, and then start trying to disassemble 
the later bytes in that instruction as other instructions.

When you hit a casel, you *know* how many bytes are a part of that 
instruction. You do *not* try to disassemble those bytes as other 
instructions. They are all a part of the casel instruction, and should 
be treated as such, not only by the CPU, but also by a disassembler, or 
the disassembler is doing it wrong. The disassembler should, after all, 
give you back something that matches what the CPU thinks is there.

	Johnny

On 2017-08-08 17:12, 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.)
>
> > 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.
>
> 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)+
>
> > > Starting disassembly in the middle of a CASE jump table is no
> > > different from starting disassembly in the middle of any other
> > > multi-byte instruction.  I would not expect a disassembler to look
> > > backwards in either case.
> > 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.
>
> 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 ASCII				  Mouse
> \ / Ribbon Campaign
>  X  Against HTML		mouse%rodents-montreal.org@localhost
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol