[LV] Can anybody build a kernel with Maciej's toolchain?

[Peter Firefly Lund]

On Wed, 2007-08-22 at 02:54 +0200, Peter Firefly Lund wrote:

So the registers were:
>            r0  3fffff25   r1  fffffffb   r2  00000024   r3  ffffffff
>            r4  00000000   r5  00000000   r6  00000006   r7  8029e9e0
>            r8  80279a66   r9  802825a0   r10 80242ae8   r11 00000000

And the code was:
>                 .size   radix_tree_node_ctor, .-radix_tree_node_ctor
>                 .section        .init.text,"ax", at progbits
>                 .align 1
>                 .type   __maxindex, @function
>         __maxindex:
>                 .word 0x0
>                 subl2 $4,%sp
>                 mull3 4(%ap),$6,%r2     # height,, tmp
>                 subl3 %r2,$31,%r1       # tmp,, tmp25
>                 mcoml $0,%r3    #, tmp27
>                 subb3 %r1,$32,%r0       # tmp25,, tmp28
>                 extzv %r1,%r0,%r3,%r0   # tmp25, tmp28, tmp27, tmp26
>                 rotl $31,%r0,%r0        #, tmp26, index
>                 bicl2 $-2147483648,%r0  #, index
>                 cmpl %r2,$31    # tmp,
>                 jlequ .L268     #
>                 movl %r3,%r0    # tmp27, index
>         .L268:
>                 ret

And a double check:
>           15:   ef 51 50 53     extzv r1,r0,r3,r0
>           19:   50 

.. just to be sure I'm not getting cheated by the toolchain using a
non-standard operand order, the way it does on IA32/AMD64 :(
51, 50, 53, 50 looks just fine.

EXTZV is the "extract bit field ("vector") and zero-extend" instruction.
The source operands are r1, r0, and r3 that describe the position of the
entire bit vector ("base.rb" = r3 does that), r1 ("pos.rl") and r0
("size.rb") describe which snippet to extract from that vector.  The
snippet gets zero-extended and written to r0 ("dst.wl").

This is the register values (if we can trust them *):
           r0  3fffff25   r1  fffffffb   r3  ffffffff

so the size is 25h, which is too big.  It can only be 0 <= size <= 32.  
I am a little bit unclear on where the source bit vector is, it can be
either in memory or in a register for this instruction.  I'm pretty sure
it is in a register (r3).  In that case pos is also wrong because it has
to be <= 31 (unsigned).

No wonder I'm getting a "reserved operand" fault.


*) The ARM says we can.  I hope SIMH does it right.  It probably does,
the main author wrote lots of VAX microcode back in the day.

-Peter

_______________________________________________
Linux-Vax mailing list
Linux-Vax at pergamentum.com
http://www.pergamentum.com/mailman/listinfo/linux-vax