On Mon, May 14, 2012 at 3:33 PM, Julius Baxter <[email protected]> wrote: > This looks really good, very well done.
Thanks :) > Can you indicate which bits are and aren't working? Maybe a summary of > some results on the opencores page would be good: > http://opencores.org/or1k/Newlib_tool_chain_test_results (I put some > stuff under gcc-4.8 maybe add a new section there) Sure. I didn't really look at the test results too hard yet. I plan on going through and figuring out what the failing test cases test for and nailing down what needs to be done. I *do* know that sibling calls aren't working properly under the no-delay-slot version. I know *what* needs to be done, I just don't know how to do it yet. Basically, once the sibling call expander is called, you can't cancel it and ask gcc to do a non-sibling call. The problem comes from the fact that the sibling call expander in some cases makes code similar to this (with delay slots enabled): l.jr r19 l.lwz r19, -4(r1) So the jump target register ends up being overwritten in the delay slot. So when delay slots are disabled, you can't just switch the order of those instructions. (That's what the code I wrote in my first try to make it work does.) You'll have to allocate another register and do a copy. But I think the sibcall expander can be executed when doing a reload, so you can't always allocate a register, but you can't cancel it either. > I recall you mentioning something about getting the no-delay-slot > stuff running Linux - is this true? No, I don't think so. This toolchain should compile it in delay-slot mode, however. One thing that needs to be done is to remove the busybox binaries from the linux tree and replace them with a script to build the initramfs from scratch. > > What's the status of GDB? I'd really like to see the sim in gdb. It's still in progress. :) I haven't done much with it, actually. > > Can you also explain a bit more what each of these macros do? Maybe in > comments. > https://github.com/pgavin/or1k-src/blob/or1k/newlib/libc/machine/or1k/include/or1k-asm.h > Sure. I'll comment them in the source files, but basically, OR1K_DELAYED accepts two instructions, and swaps their order if using delay slots. OR1K_DELAYED_NOP takes one instruction, and inserts a nop after it if using delay slots. OR1K_INST is just protects the commas embedded within the instruction from the C preprocessor. > Did you get or1ksim running the non-delay-slot code? I reckon maybe a > run-time option for this would be great. Yeah. I should push those changes, too, huh? I'll do that tonight :) The way I implemented it, if you want the simulator to run in no-delay mode, you set the ND bit in the CPUCFGR register in the config file. Then the simulator just checks this bit when it executes a jump or branch. Since mtspr shouldn't let you modify the CPUCFGR register, this should be fine. The CGEN simulator works similarly. > Again very nice. If it looks like we can pass the GCC regression suite > I'd be all for making this our mainline version. Yes, hopefully this should happen soon :) -Pete _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
