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

[Paul Koning <paulkoning%comcast.net@localhost>]

> On Jan 6, 2017, at 11:13 AM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>> 	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.

My VAX architecture handbook says that the operand type of that operand is "vb" meaning bit field and byte sized.

So yes, that looks like a wrong code bug.  Perhaps the code generator just has an incorrect operand type entry for FFS.

	paul