Re: Building current...

[Johnny Billquist <bqt%update.uu.se@localhost>]

On 2015-12-03 01:09, Christos Zoulas wrote:
> On Dec 3, 12:01am, bqt%update.uu.se@localhost (Johnny Billquist) wrote:
> -- Subject: Re: Building current...
>
> | => 0x004455ed <+75>:    extzv $0x1f,$0x1,r10,0xfffffff8(fp)
> |
> | Hmm, I can't see what's wrong. extzv with those arguments should be ok
> | according to VARM. But maybe I'm confused...?
>
> It
>
>      http://www2.hmc.edu/www_common/OVMS072-OLD/72final/4515/4515pro_018.html
>
> says:
>
> -----
> Opcodes
>
> EE	EXTV	Extract Field
> EF	EXTZV	Extract Zero-Extended Field
>
> Description
>
> For EXTV, the destination operand is replaced by the sign-extended
> field specified by the position, size, and base operands. For EXTZV,
> the destination operand is replaced by the zero-extended field
> specified by the position, size, and base operands. If the size
> operand is zero, the only action is to replace the destination
> operand with zero and to modify the condition codes.
>
> Notes
>
> 1. A reserved operand fault occurs if:
>
> 	o size GTRU 32
> 	o pos GTRU 31, size NEQ 0, and the field is contained in the registers
>
> On a reserved operand fault, the destination operand is unaffected,
> and the condition codes are UNPREDICTABLE.
>
> -----
> Here:
>
> pos == 31 (0x1f)
> size != 0 (0x1)
> field = r10
>
> So, the processor is right :-) Now how to figure out what generates this...

GTRU = Greater Than Unsigned. 31 is not greater than 31... :-)

	Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol