Project Status Report

[Chris Metcalf]

umodsi is what implements "%", so you can't implement it using gcc.  It's
like trying to write an implementation of __builtin_memcpy() for gcc by
calling memcpy() in the function body :-)

See the gcc sources (at www.tilera.com/scm) for the softdivide.c
implementation (gcc/config/tile/libgcc/softdivide.c).  When you build gcc,
you get libgcc.a, and you should just be able to link it directly into FreeBSD.

On 11/20/2010 5:29 PM, Jack Ferris wrote:
> Matt Schnall and I have spent the last few months working on this
> port. Progress has been a bit slow as this is the first time either of
> us has handled FreeBSD source/build infrastructure. Our goal is to get
> up to userland in some form by the end of our class (Dec ~10). We've
> made progress on porting over the virtual memory system, as well as
> implementing a crude version of atomic operations (more on this in a
> future message).
>
> So far, we've made it up into mi_startup and have the copyright
> message printing out.
>
> We're currently blocked on getting a few math functions to work
> (__umodsi3, __divsi3, etc). Its my understanding that these are
> normally provided by libgcc.a , but we've had trouble getting that
> built under the tile toolchain. Instead, I was trying to get these
> functions by writing c-versions, such as:
>
> unsigned int __umodsi3(unsigned int a, unsigned int b)
> {
>   return a%b;
> }
>
> which compiles down to:
>
> 000108b8 <__umodsi3>:
>    108b8:       dfdd08006b7a5000        { sw sp, lr }
>    108c0:       0833fe8ef0165000        { move r29, r52 }
>    108c8:       0833feda70165000        { move r52, sp }
>    108d0:       301f66ce70165000        { addi r28, sp, -20 }
>    108d8:       301f46db70165000        { addi sp, sp, -24 }
>    108e0:       df7508006b4a5000        { sw r28, r52 }
>    108e8:       301fe68df0165000        { addi r27, r52, -4 }
>    108f0:       0833fb6d70165000        { move r26, r27 }
>    108f8:       df6d080069da5000        { sw r26, r29 }
>    10900:       301fa68170165000        { addi r2, r52, -12 }
>    10908:       df0d0800680a5000        { sw r2, r0 }
>    10910:       301f868070165000        { addi r0, r52, -16 }
>    10918:       df050800681a5000        { sw r0, r1 }
>    10920:       301fa68070165000        { addi r0, r52, -12 }
>    10928:       301f8680f0165000        { addi r1, r52, -16 }
>    10930:       dc050800680a5000        { lw r0, r0 }
>    10938:       dc0508006c1a5000        { lw r1, r1 }
>   *** 10940:       6fff7ffff0165000        { jal 108b8 <__umodsi3> }
>    10948:       dcd508006b7a5000        { lw lr, r52 }
>    10950:       301fe68e70165000        { addi r28, r52, -4 }
>    10958:       dc75080069da5000        { lw r29, r28 }
>    10960:       0833fe9b70165000        { move sp, r52 }
>    10968:       0833fbba70165000        { move r52, r29 }
>    10970:       081606e070165000        { jrp lr }
>
>
> Now, I can't speak for the rest of this dis-assembly, but if you look
> at the instruction I starred, it *always* jumps back to the start of
> the function, and there aren't any conditionals/branches that I can
> see. This would lead me to believe this generated code is
> broken/incorrect. Unfortunately we need some working version of these
> to proceed. Does anyone have a tile version of libgcc.a? or have an
> alternative solution? If more information/context is needed, we'll try
> and do our best.
>
> -Jack

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com