Software support for RISC-V custom instructions

[Ashwini pohekar]

Hello!

I am quite new to the RISC-V ISA and related development (and computer architecture in general) so excuse me if the question might sound a bit naive.

 

From what I gather from the RISC-V ISA documentation. There is a possibility to introduce new instructions(within the given encoding scheme) which are customized for specific hardware. 

For instance, an instruction for using the h/w loop controller (instead of normal loop execution) in the design of a core using the RISC-V instruction set. In such a case, compiler modifications would be necessary. 

I wanted to know if kernel level changes would also be required in such scenario? If yes, then is there a source which could proper directions as to how such modifications can be made?

Because the base instruction set would be there and upon these the custom additions will be made, can the available kernels be used as it is even when custom instruction modifications are made ?

Thanks!

[Allen Baum]

Custom instructions are very custom - so it depends a lot on the actual instruction semantics.

For the particular case you mention, I think there would be some kernel changes, specifically if the loop controller could trap, e.g. tried to branch back to an unaligned instruction,. In that case the trap handler that looks at which instruction generated the trap would be confused by (its notion of) an undefined opcode or a non-branch that caused the unaligned branch trap cause.

There are other custom instructions that might require much more significant changes, depending on whether the cause changes in the any privileged-level state (which the above is an example of, since the trap status registers would be changed if the trap can occur). 

Another example might be if an instruction must be restartable (from the beginning or from a partially completed state).

I'm sure others that actually understand kernels could come up with a lot more examples.

But, the kernel itself isn't required to use any custom instructions; in that sense, nothing is required.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/10140138-1798-4bf4-aada-178be6a7af5a%40groups.riscv.org.

[Ashwini pohekar]

Hi Allen,

The explanation given by you makes it sufficiently clear that kernel level changes might be required based on the custom instruction that is implemented. 

Now, I have some more questions.

Here, the available software support for RISC-V is listed: https://riscv.org/software-status/

So, from what i can understand these kernels are running on the base instruction set of RISC-V(and also maybe the standard extensions) . Can changes required in kernel due to custom instructions be added onto these existing kernels? And is there a proper source from where one can follow how to make these changes?

[Ashwini pohekar]

Hi Luke,

I am not planning these things for a secret company project. Instead, my plan is to make a system on chip fo academic purposes. Specifically, to explore the possibilties of developing a system on chip for Ultra low power IoT end nodes. 

My main reference for this has been the open source PULP platform: https://www.pulp-platform.org/

Here in I saw that they have proposed diffferent cores based on the RISC-V architecture. Within a core they explore the possibilities of custom hardware blocks which is possible due to availability of Custom extensions in the ISA. They provide open source software support for all this, which is good. However, it is quite limited to what they have developed. 

If suppose I were to propose something new, I was exploring the idea of how the software system could be developed for it? I do not plan to burden anyone instead I wanted to know what is the right direction or what is even possible right now.

 

On Wed, Jan 23, 2019 at 10:25 AM Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:

On Wed, Jan 23, 2019 at 8:45 AM Ashwini pohekar <ashy...@gmail.com> wrote:
>
> Hi Allen,
>
> The explanation given by you makes it sufficiently clear that kernel level changes might be required based on the custom instruction that is implemented.
>
> Now, I have some more questions.
>
> Here, the available software support for RISC-V is listed: https://riscv.org/software-status/
>
> So, from what i can understand these kernels are running on the base instruction set of RISC-V(and also maybe the standard extensions) . Can changes required in kernel due to custom instructions be added onto these existing kernels?

hi ashwini,

the code is available: therefore as long as you respect Copyright Law
and the software license (in this case, the GPLv2), you can do what
you like: absolutely nobody can stop you.

so, *you* get to spend the time and money maintaining a hard fork of
the linux kernel, *you* get to spend time and money maintaining custom
instructions, *you* get to spend time and money implementing those
custom instructions in hardware.

as long as you do not expect *other people* to spend *their* time and
money taking upstream patches to the linux kernel that disrupt
absolutely everyone else, for no benefit or gain of anyone else other
than the company that you work for, all is well.

to do so is called "spongeing" and it is actually extremely common in
the commercial world, to treat free software developers as free (as in
unpaid) slave labour.

it's why there is a clause in the RISC-V Membership Agreement that
requires members to ensure that upstream software developers are
properly financially compensated.


what you *probably* meant to ask was, "if i make some custom
instructions, will it be *okay* to submit patches upstream so that
they are incorporated into the upstream linux kernel", and the answer
to that is, "almost certainly not".

the reasoning for that answer is as follows:

* there are only 4 custom instruction opcodes available (and 2 of
those are reserved for RV128)
* to have any of those opcodes used *PUBLICLY* requires that gcc,
llvm, binutils and all compilers support them upstream
* ONLY when the modifications to the *COMPILERS* are upstream will it
be possible to use them for the linux kernel (etc.)
* the first **PUBLIC** widespread use of those opcodes basically
destroys all and any possibility for them to be **PUBLICLY** put into
common usage by any other project or product [that also falls into the
same "public" wide-spread category].  this was discussed **AND
MISUNDERSTOOD I.E. DISMISSED AS BEING UNIMPORTANT** several months
ago.

the bottom line is: you had better have a really, *REALLY* good reason
to effectively take over (dominate) those opcodes, such as a highly
prominent, public, entirely libre project that is also on a
mass-volume (10 to 100 million units) scale.

so if you are simply doing a proprietary, secret project, where the
company is making proprietary firmware (such as a "washing machine
controller, or a PWM Stepper Motor Controller product, or an Engine
Controller Unit - ECU - for a car), that *ONLY* your company will ever
use, you clearly do not qualify, because, despite the fact that you
might sell 10 to 100 million units, you are only publishing the
*BINARIES* (if even that).

under such circumstances, *your company* has to shoulder the burden of
the cost of maintaining the hard fork of binutils, gcc, llvm *and* the
linux kernel that implements that custom instruction.

this is right and proper.

burdening other people with your company's costs (without providing
adequate financial compensation to all adversely-affected parties) is
not a reasonable expectation.  don't do it! :)


if however on the other hand, you are doing some extremely
advantageous custom instructions that *OTHER PEOPLE* might want to
implement in hardware as well, or, you are publishing for example the
FULL source code of a 3D GPU Driver and/or VPU (Video Decode driver),
which is to go into tens to hundreds of millions of products, and the
source code ends up being compiled by thousands to tens of thousands
of people world-wide, that is an entirely different matter.

under such circumstances, no matter what the RISC-V Foundation says,
the sheer overwhelming pressure from end-users, who will relentlessly
demand that the custom instructions be supported upstream due to the
*end-users* having to download the source code of a special version of
ffmpeg, a special version of gstreamer, a special version of VLC, a
special version of opengl, a special version of the linux kernel, a
special version of gcc and so on, they will get so absolutely fed up
with having to abide by such "stupid-appearing" rules that in the end
the upstream maintainers will cave in and accept that the use of the
custom instructions be de-facto standards, and the patches
[reluctantly] accepted upstream.

this scenario is one that both MIPS and ARM have noted, correctly,
that RISC-V simply has... ignored, due to lack of experience.
[however the scenario where RISC-V is used *privately* (in secret,
proprietary products) is *CORRECT*.  in secret proprietary products,
the fact that the *COMPANY* maintains *PRIVATE* hard forks means that
there is no cross-interference].


so, what precisely are you planning?  which category do you envisage
the planned custom instructions to fall into?  a proprietary secret
company project, an academic project, a libre "non-commercial" one, or
a libre mass-volume commercial one?

l.

[Ashwini pohekar]

Yes, I understand my question is looking quite vague.

To elaborate on that: For the open source PULP platform that I cited previously: https://www.pulp-platform.org/

they have proposed different cores based on the RISC-V ISA. These cores have certain custom extensions like DSP extensions for specific purposes. And they provide the software support for these. 

As a part of my research work, I am of the idea that I could make modifications to existing open source core architectures based on the RISC V (PULP being one example) so as to make the system on chip even more efficient for the ULP purposes. But the question arises, if one were to propose custom extensions (other than existing ones), then where to look for software support or better yet how to develop it by yourself. In such situation, how can the current support available on the git be useful. 

Does that make it sufficiently clear?

And thanks for your replies it is making me think about aspects that did even occur to me!

On Wed, Jan 23, 2019 at 11:35 AM Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:

On Wednesday, January 23, 2019, Ashwini pohekar <ashy...@gmail.com> wrote:

Hi Luke,

I am not planning these things for a secret company project. Instead, my plan is to make a system on chip fo academic purposes. Specifically, to explore the possibilties of developing a system on chip for Ultra low power IoT end nodes. 

Great! Sounds really interesting, and is quite clear.

 

My main reference for this has been the open source PULP platform: https://www.pulp-platform.org/

That is a really good starting point, it would save a huge amount of time.

 

If suppose I were to propose something new, I was exploring the idea of how the software system could be developed for it?

You literally just download a snapshot of the full software needed, confirm that it works, by compiling everything up and running the unit test suite, and once at a known-good state, start hacking.

Following standard software development practices, of course. Such as actually using git commits instead of doing what marvell did, which was to create 7 1.5GB "backup" zip archives of git clones of the linux kernel, not one single commit in sight!

 

 I do not plan to burden anyone instead I wanted to know what is the right direction or what is even possible right now.

The question as it stands does not make sense, because nobody can prevent or prohibit you from doing anything. So literally anything is possible (within Copyright Law).

You could add a million NOP calls as replacements for all system calls, you could completely redesign the RISCV Architecture if you wanted :)

I think what you *might* be asking is, "are there any licensing restrictions regarding the RISCV Trademark that prevent or prohibit certain possibilities?" And the answer to that, you have to know Trademark Law as well as what the Foundation wishes to assert (and what they cannot assert).

Was that more along the lines of what you meant? If yes I can clarify to the best of my unofficial understanding.

L.

--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

[Allen Baum]

I'm afraid I'm not the right person to tell you anything about SW and tools changes required for custom extensions.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CACWN5cU31khfv9HZkPF6JpS1o0F3u%2BRX7dBMUgk_aBCRr8%3DZDA%40mail.gmail.com.

[Rogier Brussee]

A while ago I proposed an interface for overloadable opcodes that, if implemented by a cpu, would allow a standardised interface for extension instructions (hence supportable by compilers) for non standard functionality e.g. from devices on a SOC. It is conceptually analogous to the way that virtual methods are a standardised interface for non standard functionality of an object or IOCTL's are a standardised mechanism for non standard commands for a device in the unix operating system.

https://libre-riscv.org/overloadable_opcodes/

Rogier.

Op woensdag 23 januari 2019 11:55:22 UTC+1 schreef Ashwini pohekar:

[Ashwini pohekar]

Ok so for SV this is the development process so far, and you would end up doing pretty much the same thing, I imagine:

* create specification for the custom extensions. Lots of dreams and nice to haves, here.

* get rocket-chip repo, build toolchain. Gcc, binutils etc.

* take git clone of spike, make public repo, start implementing SV specification

* also take git clone of riscv-tests, start creating assembly which conforms to SV, tests spike-sv mods as they are being developed.

* find out that things don't work, rip out bits of SV spec, go back three steps, carry on.

* document all this as it happens, otherwise it gets to be absolute hell.

* finally finish a suitable draft version of spike-sv, with associated fully documented draft spec, abd enough riscv-tests additions to be reasomably confident everything is hunky-dory.

... with me so far? :) >  Yes I understand this.

* next move on to hardware design and architecture. Contact comp.arch and ask for help (you may have an equivalent resource somewhere)

This person is me! I am looking at the hardware design and architecture.

* during design and high level layout, find out that many nice to have thingies are completely unrealistic. Rip them out of SV, go back 8 steps and sort out the spec, docs, spike-sv, and the hardware design > I am of the thinking that h/w modifications which are realistic only should be implemented and then you go upwards to the ISA modifications and so on.

That is where I am up to so far.  The plans are:

* to finalise a hardware design

* implement it

* make sure it passes the EXACT same riscv-tests

> Yes, perfect

That will confirm that the hardware implements the specification that includes the custom instructions, at a very low level. 

* THEN and ONLY then move on to booting a STANDARD linux kernel and OS.... *in spike* NOT in hardware.

* then try the same thing in hardware.

* then start modifying gcc and binutils to understand the new custom instructions.

* then make or find and compile some SMALL test applications, and run them under spike.

* once that works, try the hardware next.

* then move on to the linux kernel. Again, run under spike first, and hardware second.

By hardware I mean emulation, either FPGA or verilator.

The goal here is basically to bootstrap up one modification and ONE MODIFICATION ONLY at a time. > This is quite important !

So that is why I say do the spike simulator first, it will be easier and faster than trying to do only hardware, AND it will give you a baseline against which to triage hardware implementation bugs.

That will confirm that the hardware implements the 

Pleqse understand: if you try to do the hardware and the toolchain and the linux kernel all at once, you are absolutely guaranteed to fail. Don't do it! > Noted!

Work from known-good and change one thing and one thing only, using test suites and comparisons against known good things to verify that the SMALL incremental and mentally manageable change actually did the job it was supposed to.

If that sounds like it is one hell of a lot of work, that is because it is :)

Which is why I said that starting from pulpino is such a good idea, because it will save you a vast amount of time. > Yes I do plan on starting from this stage where a working system is readily available. 

From start to finish I would estimate somewhere around six to nine man-months, if the custom hardware modifications are reasonably small. > This timeline that you projeced will be quite helpful in planning my work.

Thank you! This answers so many of my questions!!

On Wed, Jan 23, 2019 at 2:55 PM Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:

On Wednesday, January 23, 2019, Ashwini pohekar <ashy...@gmail.com> wrote:

Yes, I understand my question is looking quite vague.

:)

 

To elaborate on that: For the open source PULP platform that I cited previously: https://www.pulp-platform.org/

they have proposed different cores based on the RISC-V ISA. These cores have certain custom extensions like DSP extensions for specific purposes. And they provide the software support for these. 

As a part of my research work, I am of the idea that I could make modifications to existing open source core architectures based on the RISC V (PULP being one example) so as to make the system on chip even more efficient for the ULP purposes. 

That would clearly be worthwhile. I am presently advocating the deployment of a couple of hints for stopping early speculation in out-of-order systems as they approach a known speculation fence barrier for example. That would clearly save power yet retain performance.

 

But the question arises, if one were to propose custom extensions (other than existing ones), then where to look for software support or better yet how to develop it by yourself. In such situation, how can the current support available on the git be useful. 

Does that make it sufficiently clear?

Yes.

 

And thanks for your replies it is making me think about aspects that did even occur to me!

:)

 Ok so now we get to it, and at this point the question is better suited to sw-dev, but leaving that aside... :)

Ok so for SV this is the development process so far, and you would end up doing pretty much the same thing, I imagine:

* create specification for the custom extensions. Lots of dreams and nice to haves, here.

* get rocket-chip repo, build toolchain. Gcc, binutils etc.

* take git clone of spike, make public repo, start implementing SV specification

* also take git clone of riscv-tests, start creating assembly which conforms to SV, tests spike-sv mods as they are being developed.

* find out that things don't work, rip out bits of SV spec, go back three steps, carry on.

* document all this as it happens, otherwise it gets to be absolute hell.

* finally finish a suitable draft version of spike-sv, with associated fully documented draft spec, abd enough riscv-tests additions to be reasomably confident everything is hunky-dory.

... with me so far? :)

* next move on to hardware design and architecture. Contact comp.arch and ask for help (you may have an equivalent resource somewhere)

* during design and high level layout, find out that many nice to have thingies are completely unrealistic. Rip them out of SV, go back 8 steps and sort out the spec, docs, spike-sv, and the hardware design

That is where I am up to so far.  The plans are:

* to finalise a hardware design

* implement it

* make sure it passes the EXACT same riscv-tests

That will confirm that the hardware implements the specification that includes the custom instructions, at a very low level. 

* THEN and ONLY then move on to booting a STANDARD linux kernel and OS.... *in spike* NOT in hardware.

* then try the same thing in hardware.

* then start modifying gcc and binutils to understand the new custom instructions.

* then make or find and compile some SMALL test applications, and run them under spike.

* once that works, try the hardware next.

* then move on to the linux kernel. Again, run under spike first, and hardware second.

By hardware I mean emulation, either FPGA or verilator.

The goal here is basically to bootstrap up one modification and ONE MODIFICATION ONLY at a time.

So that is why I say do the spike simulator first, it will be easier and faster than trying to do only hardware, AND it will give you a baseline against which to triage hardware implementation bugs.

That will confirm that the hardware implements the 

Pleqse understand: if you try to do the hardware and the toolchain and the linux kernel all at once, you are absolutely guaranteed to fail. Don't do it!

Work from known-good and change one thing and one thing only, using test suites and comparisons against known good things to verify that the SMALL incremental and mentally manageable change actually did the job it was supposed to.

If that sounds like it is one hell of a lot of work, that is because it is :)

Which is why I said that starting from pulpino is such a good idea, because it will save you a vast amount of time.

From start to finish I would estimate somewhere around six to nine man-months, if the custom hardware modifications are reasonably small. 

[Ashwini pohekar]

Hi Rogier!

A while ago I proposed an interface for overloadable opcodes that, if implemented by a cpu, would allow a standardised interface for extension instructions>(hence supportable by compilers) for non standard functionality e.g. from devices on a SOC. It is conceptually analogous to the way that virtual methods are a> standardised interface for non standard functionality of an object or IOCTL's are a standardised mechanism for non standard commands for a device in the unix> operating system.>

https://libre-riscv.org/overloadable_opcodes/ >

This looks very promising. It could help me in saving a lot of time in the software development. So, what is being tried to achieve here is that custom functionality is introduced in such a way the current software support does not need to be modified. Am I understanding this correctly?

Thanks!

Ashwini 

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/f53414eb-9022-456f-be73-0463bc296497%40groups.riscv.org.

[Ashwini pohekar]

Hi Rogier!

> A while ago I proposed an interface for overloadable opcodes that, if implemented by a cpu, would allow a

> standardised interface for extension instructions (hence supportable by compilers) for non standard functionality

> e.g. from devices on a SOC. It is conceptually analogous to the way that virtual methods are a standardised 

> interface for non standard functionality of an object or IOCTL's are a standardised mechanism for non standard 

> commands for a device in the unix operating system.

> https://libre-riscv.org/overloadable_opcodes/ 

This looks very promising. It could help me in saving a lot of time in the software development. So, what is being tried to achieve here is that custom functionality is introduced in such a way the current software support does not need to be modified. Am I understanding this correctly?

Thanks!

Ashwini

On Wed, Jan 23, 2019 at 6:56 PM Rogier Brussee <rogier....@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/f53414eb-9022-456f-be73-0463bc296497%40groups.riscv.org.

[Rogier Brussee]

Op donderdag 24 januari 2019 16:46:38 UTC+1 schreef Ashwini pohekar:

Hi Rogier!

> A while ago I proposed an interface for overloadable opcodes that, if implemented by a cpu, would allow a

> standardised interface for extension instructions (hence supportable by compilers) for non standard functionality

> e.g. from devices on a SOC. It is conceptually analogous to the way that virtual methods are a standardised 

> interface for non standard functionality of an object or IOCTL's are a standardised mechanism for non standard 

> commands for a device in the unix operating system.

> https://libre-riscv.org/overloadable_opcodes/ 

This looks very promising. It could help me in saving a lot of time in the software development. So, what is being tried to achieve here is that custom functionality is introduced in such a way the current software support does not need to be modified. Am I understanding this correctly?

Thanks!

Ashwini

Yes, assuming someone implements the extension in the compiler of course. It should also avoid different extensions stepping on each others toes by "claiming" the same instruction space in the custom instruction opcode space, and so make it easier to integrate cells from different parties. It also supports built in discovery of whether an interface is supported by cpu/soc/coprocessor.  It is clearly more limited than a proper instruction because of the need of specifying the 12 bit LUN in register rs1, but I tried to ensure that the XLEN-12 remaining bits are available.  I assumed that this is acceptable for many purposes. 

Many details that one could arguably change, YMMV. 

Rogier

[Liviu Ionescu]

> On 24 Jan 2019, at 19:40, Rogier Brussee <rogier....@gmail.com> wrote:
>
> Yes, assuming someone implements the extension in the compiler of course.

if the instructions are not to be used by the language itself, you can always resort to some ingeniously crafted `asm()` hex data statements. of course this is not easy and might have some drawbacks, but extending the compiler is not easy either, and, at least in the experimental phase, can be a reasonable workaround.


regards,

Liviu

[Rogier Brussee]

Yes you are right, I should have written the assembler so one can use symbolic names in asm() statements, but you are right again,  one can use hex data statements as a method of last resort. The proposed interface would require to craft such data statements once and for all for 11 instructions. 

Rogier

Op donderdag 24 januari 2019 19:01:48 UTC+1 schreef Liviu Ionescu:

[Jim Wilson]

On Thu, Jan 24, 2019 at 10:36 AM Rogier Brussee
<rogier....@gmail.com> wrote:
> Yes you are right, I should have written the assembler so one can use symbolic names in asm() statements, but you are right again, one can use hex data statements as a method of last resort. The proposed interface would require to craft such data statements once and for all for 11 instructions.

GNU as supports .insn which allows you to construct your own
instruction encodings. Kito contributed this.
https://sourceware.org/binutils/docs-2.31/as/RISC_002dV_002dDirectives.html#RISC_002dV_002dDirectives
at the end, and follow the link to the next section that explains the
instruction formats.

Using .word with a hex value also works.

Jim

[Bruce Hoult]

"For example, the instruction ‘add a0, a1, a2’ could be written as
‘.insn r 0x33, 0, 0, a0, a1, a2’."

Oh, that's interesting.

If used in inline asm from C, will this allow using variable names
instead of hardcoded registers?

> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAFyWVabo_EByb1OqjbXeJiMUW8toOWPr%3Dy7f%2BY4V3H4q4hhgdA%40mail.gmail.com.

[Jim Wilson]

On Thu, Jan 24, 2019 at 1:28 PM Bruce Hoult <bruce...@sifive.com> wrote:
> "For example, the instruction ‘add a0, a1, a2’ could be written as
> ‘.insn r 0x33, 0, 0, a0, a1, a2’."
>
> Oh, that's interesting.
>
> If used in inline asm from C, will this allow using variable names
> instead of hardcoded registers?

rohan:2183$ cat tmp.c
int
sub (int a, int b)
{
int result;
asm (".insn r 0x33, 0, 0, %0, %1, %2" : "=r" (result) : "r" (a), "r" (b));
return result;
}
rohan:2184$ riscv32-unknown-elf-gcc -O2 -c tmp.c
rohan:2185$ riscv32-unknown-elf-objdump -dr tmp.o

tmp.o: file format elf32-littleriscv


Disassembly of section .text:

00000000 <sub>:
0: 00b50533 add a0,a0,a1
4: 8082 ret
rohan:2186$

Jim

[Bruce Hoult]

Cool, thanks.