>> Interesting... Unless my memory totally fails me, the VAX very much
>> works the same way as the PDP-11, on which you really had to get
>> explicit to avoid getting PIC code.

It's not the least bit difficult to generate non-PIC code, from the
compiler author's point of view:

	static char buf[1024];
	...
	 buf[i] = '@';

		.data
	_buf:	.space	1024
		.text
	...i in r0...
		movb	$64,_buf(r0)

Indeed, in kernel code and similar places where some addresses need to
be relocated and some don't, the difference between

		movl	foo,r0
and
		movl	@$foo,r0

is critical.  If foo is relocated, the first is PIC and the second
isn't; if foo is absolute (not relocated), the second is PIC and the
first isn't.

> I forget, does the VAX have a "load address" instruction?

Yes.  If I rememebr the mnemonic correctly,

	extern void foo(void);
	extern void (*fn)(void);
	...
	 fn = &foo;

		.globl	foo
		.globl	fn
	...
		movab	foo,fn

> Pointers to data structures on the stack would have to be computed
> anyway so that shouldn't be a problem...

The "conceptually correct" way is something like

		movaX	44(sp),r0

for some X (b, w, etc), though using movaX in conjunction with
register-indirect-with-offset addressing mode like that is always
equivalent to an add, IIRC.  I don't *think* the resulting address is
run past the MMU or anything by movaX, and indeed I have seen
optimizers do things like turning

	i = (4 * b) + c + 17;
into
		moval	17(r1)[r2],r3

(where c is in r1, b in r2, and i in r3).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B