From owner-freebsd-tilera@FreeBSD.ORG Sat Nov 20 22:50:40 2010 Return-Path: Delivered-To: freebsd-tilera@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E42051065673 for ; Sat, 20 Nov 2010 22:50:39 +0000 (UTC) (envelope-from cmetcalf@tilera.com) Received: from USMAMAIL.TILERA.COM (206.83.70.70.ptr.us.xo.net [206.83.70.70]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5978FC0A for ; Sat, 20 Nov 2010 22:50:36 +0000 (UTC) Received: from [192.168.1.103] (24.34.76.130) by USMAExch2.tad.internal.tilera.com (10.3.0.33) with Microsoft SMTP Server id 14.0.694.0; Sat, 20 Nov 2010 17:39:47 -0500 Message-ID: <4CE84E32.1060200@tilera.com> Date: Sat, 20 Nov 2010 17:39:46 -0500 From: Chris Metcalf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jack Ferris References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: freebsd-tilera@freebsd.org Subject: Re: Project Status Report X-BeenThere: freebsd-tilera@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: List for porting FreeBSD to the Tilera family of CPUs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 22:50:40 -0000 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 From owner-freebsd-tilera@FreeBSD.ORG Sat Nov 20 22:56:25 2010 Return-Path: Delivered-To: freebsd-tilera@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBE35106566B for ; Sat, 20 Nov 2010 22:56:24 +0000 (UTC) (envelope-from jhferris3@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7ED878FC0A for ; Sat, 20 Nov 2010 22:56:24 +0000 (UTC) Received: by bwz2 with SMTP id 2so5172593bwz.13 for ; Sat, 20 Nov 2010 14:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=2xCRuKVR4ohyf2H9hUVsZREJX2QlacI5jtLLqJ6DbtU=; b=WRkuFjP46SkBQSHw0qrRfC++hgwc2gDCcULyTL6Tpd2PVpPTXTUU6gZ7xqabU16WJv +5HgcvRnhVU9KSZSaDz1C0CgsM0Lv/FzQEHflQG7eMiJ4OSNhxOmczH8Hot7Q5kzcJKz LtNF6tRRMx8puadvqN1d6U3zeItP64ngEvcBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=gtCzfkHbVmXozzDB775n6Z0bRAWwHQ0cEPJeJKY90TTepCbyCMznVF9TlaXidLyPAP +Gf3+R5MPF2QLo3tvRmPOBgFCZW86wcig3CD0263yI9GIGzTkyK04+sA08h07CddH38N R+44eFwMRZIiNGqqE+eNsOy+ibbelnJEdpyIY= MIME-Version: 1.0 Received: by 10.204.97.143 with SMTP id l15mr3661971bkn.127.1290292188911; Sat, 20 Nov 2010 14:29:48 -0800 (PST) Received: by 10.204.113.198 with HTTP; Sat, 20 Nov 2010 14:29:48 -0800 (PST) Date: Sat, 20 Nov 2010 17:29:48 -0500 Message-ID: From: Jack Ferris To: freebsd-tilera@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Project Status Report X-BeenThere: freebsd-tilera@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: List for porting FreeBSD to the Tilera family of CPUs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 22:56:25 -0000 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