[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: gcc vax bug in built-in ffs function/displacement indexed addressing
> 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
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.
Main Index |
Thread Index |