Align bitmanip instructions with v.1.00 and draft v.0.93 of the spec

[vogelpi]

In particular:

• Zbb: Rename pcnt* instructions to cpop*
• Zbs: Rename sb* instructions to b*
• Zbe: Rename bext*/bdep* insctructions to bcompress*/bdecompress*. Stricly speaking this only happens as part of v.0.94. But without this change, there are two bext instructions (the other one from Zbs due to renaming sbext to bext).
• Zbp: Re-add slo[iw], sro[iw]. These are still listed in v.0.93 and even v.0.94.
• All: Rename *u.w instructions to *.uw
• Zbp: Fix XLEN for xperm.w

[cmuellner]

Binutils support has already been merged upstream and is maintained there.
See https://sourceware.org/git/?p=binutils.git;a=summary

[vogelpi]

Thanks for the quick response @cmuellner ! The stuff at the posted link seems to be outdated (from 2013).

Anyway, what I should probably have clarified: even though bitmanip v.1.00 is now getting included upstream, there are still plenty of instructions in the draft v.0.93 that are not part of v.1.00 and thus will not be upstreamed. My understanding is that these instructions remain part of the draft bitmanip extension which is continued to be developed.

This PR aligns the riscv-binutils-2.35-rvb branch with what's in v.1.00 and the other instructions remaining in draft v.0.93. Without this patch, the encodings are in an in between state:

• some are v.1.00 (most of Zbb)
• some v.0.93 (xperm)
• some are v.0.92 (e.g. cpop from Zbb, full Zbs, both of which are in fact ratified and thus in v.1.00)

So the intent of this PR is to provide a basis for people needing both the ratified and draft parts of the extension.

[cmuellner]

Sorry, I copied the wrong link. Here is the correct one: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git
One patch of the recent series of updates for the ratified version of Zb* can be found here:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=586dcfc81ee4a24c150362c624a47d633e4d6bdc

I am not aware of any plans regarding the instructions, which did not make it into the ratified Zb* specification.
The assumption that these instructions will get into another ratified specification is likely to fail.
If a new TG is spun up to work on a specification for additional Zb* instructions, the SW support would be implemented on top of upstream/master and not revive an outdated branch.

Regarding the branch, you want to add your changes to:
It was used to collect changes, but it is not actively maintained anymore.

Also note, that we cannot support instructions, that are specified in outdated versions of a specification.
Especially if a ratified version of that specification exists already.

[jim-wilson]

Another problem is that this branch contains work that we can't upstream. If there is work here that needs to be preserved, it would be better to create a new clean branch that contains only work that is upstreamable. That is, we need to start with upstream sources, and then start adding patches from known people with the necessary paperwork.

Speaking of which, patches for GNU tools require a copyright assignment or for gcc optionally a DCO instead. I checked the FSF and I don't see a copyright assignment for you. If your employer has an assignment that can work, but I don't know who you work for. If you are serious about contributing, then you or your employer should sign an FSF copyright assignment. We can't accept patches from you without one. You can start the process by sending email to assign@gnu.org and stating what you want to contribute to (e,g, binutils, gcc, gdb, glibc). We either need a personal assignment from you and a disclaimer from your employer, or an assignment from your employer. The latter is generally better if multiple people want to contribute, but is much harder to get as some companies won't sign them. If you want to contribute to multiple projects, you may need multiple assignments/disclaimers.

[vogelpi]

Thanks for clarifying the situation @cmuellner and @jim-wilson . I agree it doesn't make sense to merge this PR. I should probably first ask in the bitmanip repository what the best way forward is.

However, I suggest to leave this PR open for the moment as there is, at least to my knowledge, no other binutils version available that supports v.1.00 + v.0.93 of the bitmanip spec. But there are still hardware implementations that have support for the bitmanip instructions not part of v.1.00. This is also why I did this work. As I am not very experienced with compilers/binutils, starting from upstream would have been out of scope for me but starting from this branch was feasible. I just needed something to verify our hardware.

Regarding the copyright assignment: I am working for lowRISC. It's possible that we already have an assignment but I am not sure. I can check internally next week.