Date: Sat, 20 Nov 2010 17:39:46 -0500 From: Chris Metcalf <cmetcalf@tilera.com> To: Jack Ferris <jhferris3@gmail.com> Cc: freebsd-tilera@freebsd.org Subject: Re: Project Status Report Message-ID: <4CE84E32.1060200@tilera.com> In-Reply-To: <AANLkTint%2BHAjhj8PZch1iv7nb2zrZ0s8oH2d-ewZaQdV@mail.gmail.com> References: <AANLkTint%2BHAjhj8PZch1iv7nb2zrZ0s8oH2d-ewZaQdV@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE84E32.1060200>