> I am looking at objdump output of VS 4k60 system ROM.  Since i'm
> unfamiliar with the types of operands and Vax Architecture Handbook
> doesn't help with these i washoping somebody could clarify few issues
> for me :-)

Ah, something I can handle.  (I went through my larval stange on VAXen.)

> What do *, $ and lack of either of those mean in front of an operand?

* means what DEC documents spell @, and similarly for $ and #.

> moval 0x000000ff, *0x10000000

MOVe Address of Long
src operand: PC-relative address 0xff
dst operand: indirect through PC-relative address 0x10000000

DEC syntax for this would be "MOVAL 0xff, @0x10000000".

> I'm also puzzled by the lack of register name at many mtpr/mfpr
> instructions - examples would be mtpr $0x0, $0x25.  Are some
> registers referred to in ways other than r0, r1, r2, etc. or what ?

Yes.  mfpr/mtpr access certain internal registers that are not part of
the normal programmer model; they are implementation-specific and
privileged (mfpr/mtpr trap if executed in other than kernel mode).
mtpr $0,$0x25 moves zero into internal register number 37 (0x25).  This
particular register is documented as being the cache disable register
on an 11/750; I don't know what it might be on a 4k.

> (r1) seems to be the value contained at address pointed to by
> register r1, as in index addressing, is that correct ?

If r1 contains the value 0x5678, then "movl (r1),r2" moves the 32-bit
("l") value from memory at 0x5678 - ie, assembled from the bytes at
0x5678, 0x5679, 0x567a, and 0x567b - into r2.  I think that's what you
meant, and if so, that's a yes.

> If that is correct 5(r1) would be interpreted as "address of data
> pointed to by r1 + 5" ?  Index 5 is the number of operand-sized
> elements, right ? 4 for long, 2 for word, 1 for byte, etc. ?

Yes to the first question, no to the second.  5(r1) is the same as
above, except the 5 is added to r1 first.  The 5 is not affected by the
size of the operand; if that's what you want, you have to use what the
VAX calls index mode (not the same thing as what you called index
addressing above), which would be something like (r1)[r2] where r2
contains the index value.  "movw (r1)[r2],r3" says "take the value in
r2, multiply by 2 (size of "w"), add to the value in r1, fetch the
16-bit ("w") value from that location, and put it in (the low half of)
r3".

> What is *5(r1) then ?

"Take the value in r1, add five to it, fetch the 32-bit value from that
address, then the operand is the memory at _that_ location."  If, for
example, r1 contains 0x49ff and memory contains
	0x00004a04:	0xf0
	0x00004a05:	0x27
	0x00004a06:	0x00
	0x00004a07:	0x01
	0x010027f0:	0x74
	0x010027f1:	0x2f
then "movw *5(r1),r2" would put 0x2f74 into the low half of r2: r1+5 is
0x4a04; it loads a 32-bit value from there (0x010027f0) and then uses
that as the address of the operand.

> This covers almost all the cases i have found so far, except for nice
> complicated stuff like movab 8(r9)[r1],r0 - what the heck is first
> operand here ?

8(r9)[r1] is.  This is actually a vaguely clever way to write "compute
r1+r9+8 and put it in r0".  It says "the operand is pointed to by r9,
offset by 8, indexed by r1".  Because the operand is byte sized (the
trailing "b"), the indexing by r1 multiplies r1 by 1.  The operand is
thus "the byte at address r9+8+r1".  Because it's movab rather than
movb, it moves not the operand (the byte), but rather the address of
the operand, into r0.  I think the mova? instructions are specified
such that the address of the operand does not actually need to be a
valid address, and they thus can be used as substitutes for certain
arithmetic conmbinations.  (Things such as "movab r2,r0" trap, because
the operand does not have an address.)

> I need a decent book on Vax assembly, something that is compatible
> with objdump output :(

The architecture reference manual should be clear, once you get the
@<->* and #<->$ mappings straightened out.  DEC uses @ and #, but
Unices have traditionally used * and $.  I'll be happy to help where I
can if you get stuck.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B