Re: gcc vax bug in built-in ffs function/displacement indexed addressing

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 	bit = ffs(periph->periph_freetags[word]);

> is compiled as

>      15b0:	ea 00 20 48 	ffs $0x0,$0x20,0x50(r10)[r8],r9
>      15b4:	aa 50 59

> which is obviously wrong, as r8 seems to be a byte index, but
> variable "word" is an index into u_int32_t periph_freetags[].

I'm not so sure.  The indexed addressing modes (the [r8] part) multiply
the index by the size of the operand.  If ffs considers that operand to
have byte size, you are correct, but if longword size, the code is
fine.  My guess is that gcc's description thinks it's longword but the
hardware thinks it's something else, probably byte; that would account
for the problem very neatly.

I dug out my transcription of EL-00032-00-decStd32_Jan90.pdf.  3.3,
BIT-FIELD INSTRUCTIONS, says that the base address "is obtained from an
operand of address access type", but I have so far completely failed to
find any clear statement of what operand size is used for bit-field
operands.

At some point I thought it was byte, because that's what my VAX
emulator uses, but I'm not sure where I got that idea - was it a guess,
or is there something in the VARM I've missed in my quick searches now,
or what....

/~\ 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