Re: Help decoding a vax instruction

[coypu%sdf.org@localhost]

On Wed, Aug 21, 2019 at 01:21:17PM +0200, Anders Magnusson wrote:
> Den 2019-08-21 kl. 12:11, skrev coypu%sdf.org@localhost:
> > hi folks,
> > 
> > I'm a vax newbie. What does this one do?
> > 
> >     c:	98 40 a0 02 	cvtbl 0x2(r0)[r0],15 <e+0x15>
> > 
> Heh!
> 
> cvtbl = sign-extend byte into long
> 
> 2(r0)[r0] = 2+r0+sizeof(byte)*r0.  Indexing, similar exists on x86. Uses
> source size (b) for indexing size.
> 
> 15 = address 15 in memory.
> 
> -- R

Seems to be an addressing mode that GCC/vax struggles with. Using the
following code (-O2 -c)

int a, b;
int e() {
  short *c = 0;
  char d = c[a + 1];
  b = d;
  a += 2;
}

I hit an assert

emit-rtl.c:2310 gcc_assert (memory_address_addr_space_p (mode, addr, as));

this seems to be down to vax specific code, vax_legitimate_address_p.
It seems like it can't handle it.

There's code to handle offset(reg)[index]. I'm not sure if it's meant to
handle this case. What's true is that
 if (!CONSTANT_ADDRESS_P (xfoo0))
   return false;

is the codepath both xfoo0 and xfoo1 take.

I'm still staring at it.

(I'm building unmodified GCC with our vax code. NetBSD GCC has a local
modification causing it to hit another compiler error, most likely this:
https://github.com/NetBSD/src/commit/e437e96750193b86d0464965661f616e011056fa
my patches are at:
https://github.com/coypoop/gcc/tree/vax3 )