On Wed, Oct 31, 2012 at 3:49 AM, Peter Gavin <[email protected]> wrote: >> Otherwise, as long as it passes the test suite that should be fine. I >> guess it should live in a branch until the re-branded or1k tool chain >> becomes the norm. Hopefully that's pretty soon, though. > > Hopefully :) Stefan is doing an awesome job with the PIC stuff. But > I think as long as it compiles the linux kernel and busybox, it's > pretty close to where it was before, right? > > I think I'm going to try getting linux working on the nodelay version; > that would only involve porting the assembly files in the arch/or1k > subdirectory, I hope. And I'd like to write a script to build busybox > from source, rather than having precompiled binaries in the git repo. >
A couple of heads-up regarding the PIC work and no-delay: 1) as I mentioned in the or1k-src patches I posted, (some of) the plt entries need no-delay counterparts As I mentioned in that thread, it should be straight forward to fix, PLT entry instructions 3 and 4 should be swapped here: https://github.com/openrisc/or1k-src/blob/or1k/bfd/elf32-or1k.c#L1458 and here https://github.com/openrisc/or1k-src/blob/or1k/bfd/elf32-or1k.c#L1544 2) The fetching of the PC value in gcc uses a hardcoded l.jal 8 ;; The insn to set GOT. ;; TODO: support for no-delay target (define_insn "set_got" [(set (match_operand:SI 0 "register_operand" "=r") (unspec:SI [(const_int 0)] UNSPEC_SET_GOT)) (clobber (reg:SI 9)) (clobber (reg:SI 16))] "" "l.jal \t8 \tl.movhi \tr16,gotpchi(_GLOBAL_OFFSET_TABLE_-4) \tl.ori \tr16,r16,gotpclo(_GLOBAL_OFFSET_TABLE_+0) \tl.add \tr16,r16,r9" [(set_attr "length" "16")]) The "quick and dirty" fix is obviously to just add a seperate "set_got_nodelay" instruction, but I think it'd be nicer to remove this and emit a label that we jump to and let the delay slot filler insert a nop between the l.jal and the label for the delay slot version. This is how I do it in LLVM, but I haven't figured out how to trick gcc into doing the same. And another heads-up related to this: As Yann Vernier pointed out during the openrisc meeting, the PC fetching will not work in "compatibility mode". Apart from that, if it's not something I am forgetting, I believe I have took care of making the changes compatible with no-delay. But having no-delay slot in or1ksim makes it possible to start working on the issues and actually test them, nice job! (And also nice job on all the toolchain stuff you've done!) Stefan
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
