So I guess I'll hold off with this patch until we know that or1knd will be a thing in the binutils port (as in: if or1knd get accepted in binutils, I will submit this patch).
Stay tuned On Sun, Mar 9, 2014 at 2:00 PM, Christian Svensson <[email protected]> wrote: > Actually, looking at the code - it appears we have these things today: > > From gcc/config/or1k/or1k.opt: >> mdelay >> Target RejectNegative Negative(mno-delay) Var(or1k_delay_selected, >> OR1K_DELAY_ON) >> Assume branches and jumps have a delay slot >> mno-delay >> Target RejectNegative Negative(mcompat-delay) Var(or1k_delay_selected, >> OR1K_DELAY_OFF) >> Assume branches and jumps do not have a delay slot >> mcompat-delay >> Target RejectNegative Negative(mdelay) Var(or1k_delay_selected, >> OR1K_DELAY_COMPAT) >> Assume branches and jumps have a delay slot, but fill them with nops > > Building for or1knd sets OR1K_DELAY_DEFAULT=OR1K_DELAY_OFF (from > gcc/config.gcc) which sets the default for or1k_delay_selected, which > seems to be the variable overrideable by the flag. > Building a gcc for or1knd would simply use mno-delay as the default, > if I understand the code correctly. > > To me using the target to specify these things seems like the correct > thing to do. > > On Sun, Mar 9, 2014 at 1:50 PM, Christian Svensson <[email protected]> wrote: >> Hi, >> >> I guess so. Aarch64 has aarch64_be IIRC. In that case it would be >> or1k_le and or1knd_le. >> >> or1knd has a non-trivial presence in our code base, and it changes a >> quite fundamental assumption of the or1k architecture. >> Running or1knd code on or1k (or the other way around) would certainly >> produce all kinds of weird results, I'm not sure it's something you >> would like to tweak with a flag. Possibly we could add a flag to make >> the code generated usable for both by always putting nop where the >> delay slots would be. >> >> On Sun, Mar 9, 2014 at 1:38 PM, Jeremy Bennett >> <[email protected]> wrote: >>> On 09/03/14 10:19, Christian Svensson wrote: >>>> Hi, >>>> >>>> nd in or1knd is stands for No Delay. It's or1k but with no delay slot. >>> >>> Hi Christian, >>> >>> I do rather wonder if this justifies having a different architecture >>> name. I would expect it to be an option in the tool chain (-mno-delay >>> for example). >>> >>> The usual case where you have variants in the architecture name is for >>> endianness. For example arc (little-endian) and arceb (bit-endian). What >>> do we do about the little-endian variants of OR1K. Do we have or1kndel >>> and or1kel? >>> >>> >>> Jeremy >>> >>>> On Sun, Mar 9, 2014 at 9:49 AM, Geert Uytterhoeven <[email protected]> >>>> wrote: >>>>> On Sat, Mar 8, 2014 at 2:56 PM, Christian Svensson <[email protected]> >>>>> wrote: >>>>>> Since binutils contains code that targets or1knd, I'm going to submit >>>>> >>>>> Pardon my ignorance, but what's the difference between or1k and or1knd? >>>>> I tried Google, but didn't become wiser. >>>>> >>>>> Thanks! >>>>> >>>>> Gr{oetje,eeting}s, >>>>> >>>>> Geert >>>>> >>>>> -- >>>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- >>>>> [email protected] >>>>> >>>>> In personal conversations with technical people, I call myself a hacker. >>>>> But >>>>> when I'm talking to journalists I just say "programmer" or something like >>>>> that. >>>>> -- Linus Torvalds >>> >>> >>> -- >>> Tel: +44 (1590) 610184 >>> Cell: +44 (7970) 676050 >>> SkypeID: jeremybennett >>> Twitter: @jeremypbennett >>> Email: [email protected] >>> Web: www.embecosm.com >> _______________________________________________ >> Openrisc mailing list >> [email protected] >> http://lists.opencores.org/listinfo/openrisc _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
