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