[OpenRISC] OpenRISC GCC requirements

[OpenRISC] OpenRISC GCC requirements

[Stafford Horne]

Hi All,

As many of us know OpenRISC has different classes for instructions.
i.e. Class I and Class II.

The Class I instructions are required for all implementation and Class
II instructions are optional.   For the new GCC port I have used a few
class II instructions.

Does anyone have any opinion if this would be bad or cause issues?  To
me I think its OK as I haven't seen a core without these.

Class II Instructions used:
       l.extbs  - sign extend byte
       l.extbz  - zero extend byte
       l.exths  - sign extend half-word
       l.exthz  - zero extend half-word
       l.cmov  - conditional move


The alternative would be to substitute the instructions with something
else.   But I don't expect there would be many/any cores running C
code that would be missing these instructions.

-Stafford

[OpenRISC] OpenRISC GCC requirements

[BAndViG]

Stafford,

If I remember correctly, all of these instructions are disabled by default. 
Moreover, most of mor1kx pipes support l.cmov only if FEATURE_CMOV is 
"ENABLED", while l.ext* instructions aren’t implemented at all. Even so 
FEATURE_EXT is present in source code it's only legal value is "NONE".
The only mor1kx pipe which supports l.cmov permanently is MAROCCHINO, but 
following others MAROCCHINO doesn't support l.ext* too.

WBR
Andrey 

[OpenRISC] OpenRISC GCC requirements

[Samuel Holland]

On 09/07/18 06:27, Stafford Horne wrote:
> As many of us know OpenRISC has different classes for instructions.
> i.e. Class I and Class II.
> 
> The Class I instructions are required for all implementation and Class
> II instructions are optional.   For the new GCC port I have used a few
> class II instructions.
> 
> Does anyone have any opinion if this would be bad or cause issues?  To
> me I think its OK as I haven't seen a core without these.

I know of at least one currently-produced silicon implementation[1] based on an
old or1200 that has a broken l.cmov.

[1]: https://linux-sunxi.org/AR100

> Class II Instructions used:
>        l.extbs  - sign extend byte
>        l.extbz  - zero extend byte
>        l.exths  - sign extend half-word
>        l.exthz  - zero extend half-word
>        l.cmov  - conditional move

Looking at or1k.md, you used l.msync and l.ror, and l.sf*i as well. And l.cmov
and l.sf*i are also used in the libgcc implementation. Those also need to be
considered.

> The alternative would be to substitute the instructions with something
> else.   But I don't expect there would be many/any cores running C
> code that would be missing these instructions.
> 
> -Stafford

Thanks,
Samuel

[OpenRISC] OpenRISC GCC requirements

[Stafford Horne]

On Fri, Sep 07, 2018 at 05:29:09PM -0500, Samuel Holland wrote:
> On 09/07/18 06:27, Stafford Horne wrote:
> > As many of us know OpenRISC has different classes for instructions.
> > i.e. Class I and Class II.
> > 
> > The Class I instructions are required for all implementation and Class
> > II instructions are optional.   For the new GCC port I have used a few
> > class II instructions.
> > 
> > Does anyone have any opinion if this would be bad or cause issues?  To
> > me I think its OK as I haven't seen a core without these.
> 
> I know of at least one currently-produced silicon implementation[1] based on an
> old or1200 that has a broken l.cmov.
> 
> [1]: https://linux-sunxi.org/AR100
> 
> > Class II Instructions used:
> >        l.extbs  - sign extend byte
> >        l.extbz  - zero extend byte
> >        l.exths  - sign extend half-word
> >        l.exthz  - zero extend half-word
> >        l.cmov  - conditional move
> 
> Looking at or1k.md, you used l.msync and l.ror, and l.sf*i as well. And l.cmov
> and l.sf*i are also used in the libgcc implementation. Those also need to be
> considered.

Thanks, so it looks like we will have to make a flag to enable/disable the class
II instructions to be generated in the output code.

Thanks for the details.  I didnt know it was such a large set of cores missing
those instructions.

-Stafford

[OpenRISC] OpenRISC GCC requirements

[Stafford Horne]

On Sat, Sep 8, 2018 at 9:29 AM, Stafford Horne <shorne@gmail.com> wrote:
> On Fri, Sep 07, 2018 at 05:29:09PM -0500, Samuel Holland wrote:

>> Looking at or1k.md, you used l.msync and l.ror, and l.sf*i as well. And l.cmov
>> and l.sf*i are also used in the libgcc implementation. Those also need to be
>> considered.
[...]
> Thanks for the details.  I didnt know it was such a large set of cores missing
> those instructions.

Hello,

I have posted a few patches to allow enabling of the class2
instructions (disabled by default).  To view the changes so far see:

     https://github.com/stffrdhrn/gcc/commits/or1k-port-1

Currently the architecture related openrisc gcc arguments are:

    -mclass2 - enable class 2 instructions (other than div/mul)
    -mhard-div - enable hardware divide instruction
    -mhard-mul - enable hardware multiply instruction

I couldn't really think of a good way to go about the naming, so that
is what I came up with.

Also, currently I didn't not add mclass2 as a 'multilib' argument.  So
libgcc will build with class2 instructions disabled.  If enabled it
would mean we would generate 8 versions of libgcc.  Maybe thats fine.
Anyone have opinions?

-Stafford

[OpenRISC] OpenRISC GCC requirements

[BAndViG]

>Currently the architecture related openrisc gcc arguments are:

>    -mclass2 - enable class 2 instructions (other than div/mul)
>    -mhard-div - enable hardware divide instruction
>    -mhard-mul - enable hardware multiply instruction

What about to follow the approach implemented in current GCC? I.e. use 
separate options: -mcmov, -mror, -msext, and additional to 
them: -mmac, -madrp. For example, various "multiply-accumulate" instructions 
are also Class-II, however I doubt that they are implemented elsewhere than 
simulator. I think, multilib configuration could be given just as a 
relatively simple example (with short list of variants) in commentaries in 
appropriate file ("gcc/config/or1k/t-or1k" if I remember correctly) , while 
default should be minimum set (i.e. just class-I).

WBR
Andrey

[OpenRISC] OpenRISC GCC requirements

[Stafford Horne]

On Fri, Sep 14, 2018, 2:57 AM BAndViG <bandvig@mail.ru> wrote:

> >Currently the architecture related openrisc gcc arguments are:
>
> >    -mclass2 - enable class 2 instructions (other than div/mul)
> >    -mhard-div - enable hardware divide instruction
> >    -mhard-mul - enable hardware multiply instruction
>
> What about to follow the approach implemented in current GCC? I.e. use
> separate options: -mcmov, -mror, -msext, and additional to
> them: -mmac, -madrp. For example, various "multiply-accumulate"
> instructions
> are also Class-II, however I doubt that they are implemented elsewhere
> than
> simulator. I think, multilib configuration could be given just as a
> relatively simple example (with short list of variants) in commentaries in
> appropriate file ("gcc/config/or1k/t-or1k" if I remember correctly) ,
> while
> default should be minimum set (i.e. just class-I).
>

Thanks,

That makes sense.  My though was to first have the mclass2 blanket argument
to enable everything.  Then, if anyone wants to have instruction specific
switches it should be pretty easy to add.  So I don't plan to add at first.
Is that fair?

One thing I will do now is expose these via configure as suggested by
Samuel. I.e. ./configure --enable-class2.

Note, my most recent patches have cause a few hundred tests to fail. Please
use the releases from GitHub if you want to play with the toolchain.

-stafford
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20180914/0f2b482f/attachment.html>

[OpenRISC] OpenRISC GCC requirements

[BAndViG]

>My though was to first have the mclass2 blanket argument to enable everything.  
>Then, if anyone wants to have instruction specific switches it should be pretty easy to add.  
>So I don't plan to add at first. Is that fair?

Yes, absolutely.

>One thing I will do now is expose these via configure as suggested by Samuel. 
>I.e. ./configure --enable-class2.

I think, it would be useful to implement similar ability for each “–m*” option. The approach is more elegant than editing source code to select default options configurations.

>Note, my most recent patches have cause a few hundred tests to fail. 
>Please use the releases from GitHub if you want to play with the toolchain.

It is exaclty which I do.

WBR
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20180917/845be244/attachment.html>