But actually, the primary reason I added the new arch name was to let the user configure the toolchain with --target=or1knd-elf or whatever, instead of having to figure out how to force GCC to always use -mno-branch-delay. I figured it was safer.
But in the end, gcc will be able to compile with or without delay slots, no matter which arch name is used, just by passing the appropriate flags. -Pete On Wed, Apr 25, 2012 at 2:29 PM, Peter Gavin <[email protected]> wrote: > On Wed, Apr 25, 2012 at 2:17 PM, R. Diez <[email protected]> wrote: >> >> >>> GCC defines __or1k__, so I was going to make it define __or1knd__ if >>> no delay slots are used, to match what I'm calling the no-delay-slots >>> architecture. >> >> Is it worth defining a new architecture name like __or1knd__? After all, we >> have only one toolchain and the delay slot is just an option. >> rdiez > > Perhaps not. But it makes it less likely that people will try mixing > code that uses a delay slot with code that doesn't. > > But I think I've got bfd set up now so that it will set a flag in the > ELF header indicating the binary doesn't use delay slots. I also > added a ".nodelay" directive to GAS that indicates that as well. That > way when GCC compiles something without delay slots, it can indicate > it in the assembly file, and it will be carried all the way down to > the binary. > > So perhaps a separate arch name isn't needed. > > -Pete _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
