RV32I executable on RV64 Architecture

[Vinod Ganesan]

Hi

I am running a 32-bit application on a 64-bit RISC-V architecture. It accesses a 32-bit address space via 32-bit bus

I am having issues with running programs as RV32I is not a subset of RV64I instruction set.For eg

an instruction like SLLI corresponds to 32-bit shift on RV32 whereas it corresponds to 64-bit shift on RV64I (same opcode, functionally different)

Is there an option 

1. To select 32-bit instruction subset of RV64I or
2. force my ABI to be 32 bit  with an option --march rv64imafd --abi ilp32 so that my pointers are 32 bit

I did follow the previous article where it was debated that it was not possible to run a 32-bit application on a 64-bit architecture as RV32I is not a proper subset of RV64I (https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/nkiTe3stA2o) and ABIs are not available to do so. But I feel that many people would've faced this issue and would've been looking for or be trying to arrive at a solution. Just wanted to know if there are any current developments on this front which enables me to run the same?

[Tommy Murphy]

You mention a previous thread asking about running rv32 programs on rv64 and as you say the answer then was that this was not possible.

I don't believe that anything has changed since nor did I ever see anything suggesting that it would.

My understanding is that rv64 will never be able to run rv32 code "natively" whatever about using emulation etc.

[Tommy Murphy]

I think that this is the aforementioned thread in question?

https://groups.google.com/a/groups.riscv.org/forum/?utm_medium=email&utm_source=footer#!topic/isa-dev/eOQ6xN9pzrs

[Richard Herveille]

This is not possible.

I faced the same issue …

 

Richard

 

 

 

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

 

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/490d01d0-3f97-42f8-be21-15dda4de118e%40groups.riscv.org.

[Cesar Eduardo Barros]

The solution people arrived at is to make it possible to switch the base
ISA between RV64 and RV32. If the processor you are using supports it,
see the MXL field in the MISA register (for M-mode), and the SXL and UXL
fields in the MSTATUS/SSTATUS registers (for S-mode and U-mode).

--
Cesar Eduardo Barros
ces...@cesarb.eti.br

[Tommy Murphy]

Was this discussed somewhere?

I don't recall seeing anything about it on the mailing lists. 

[Richard Herveille]

This is specified in Privileged Spec 1.10 and beyond.

 

Richard

 

 

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

.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/eb1eaa58-b838-4ddf-9e12-ceccfea3e34c%40groups.riscv.org.

[Neel Gala]

in the privilege spec section 3.1.1 explains how MXL/SXL/UXL fields can be used to change the operands to be treated as 32/64/128 bits:

from privilege spec:

"When MXL is set to a value less than the widest supported XLEN, all operations must ignore

source operand register bits above the configured XLEN, and must sign-extend results to fill the

entire widest supported XLEN in the destination register."

@Cesar,

Just to confirm, this enhancement will allow to me compile an application using the riscv32-unknown-* toolchain and then run the binary on a 64-bit core with MXL/SXL/UXL set to 1. Am I right?

On Thu, Apr 26, 2018 at 4:49 PM, Richard Herveille <richard....@roalogic.com> wrote:

 

On 26/04/2018, 13:12, "Tommy Murphy" <tommy_...@hotmail.com> wrote:

 

On Thursday, 26 April 2018 11:27:06 UTC+1, Cesar Eduardo Barros wrote:

Em 26-04-2018 06:38, Vinod Ganesan escreveu:  

The solution people arrived at is to make it possible to switch the base
ISA between RV64 and RV32. If the processor you are using supports it,
see the MXL field in the MISA register (for M-mode), and the SXL and UXL
fields in the MSTATUS/SSTATUS registers (for S-mode and U-mode).

--
Cesar Eduardo Barros
ces...@cesarb.eti.br

 

Was this discussed somewhere?

I don't recall seeing anything about it on the mailing lists. 

 

This is specified in Privileged Spec 1.10 and beyond.

 

Richard

 

 

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to

sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit

https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/eb1eaa58-b838-4ddf-9e12-ceccfea3e34c%40groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/B79DEA4B-9DE1-431C-8E0E-099B08CED765%40roalogic.com.

--

Neel Gala

Senior Project Officer

RISE LAB, IIT-Madras

[Tommy Murphy]

Thanks for the priv spec reference Richard.

I still don't remember any discussion of this here.

I presume when you said that this was not possible above you meant with implementations not conforming to the (draft) priv spec 1.10 yet?

[Richard Herveille]

Correct, a plain RV64 CPU, without the M/S/UXL bits implemented, cannot run native RV32 code.

 

Richard

 

 

[Tommy Murphy]

Bear in mind that the riscv64-unknown-elf toolchain can compile rv32 programs if configured and built appropriately - particularly the multilib support.

When compiling your program what -march and -mabi are you referring to?

-march=rv32i -mabi=ilp32 or something else?

If the *XL bits can be used to support rv32 on rv64 (as seems to be suggested by the priv spec) then something will presumably need to change the *XL bit(s) before the rv32 program starts running?

[Richard Herveille]

 

 

On 26/04/2018, 13:43, "Tommy Murphy" <tommy_...@hotmail.com> wrote:

 

Bear in mind that the riscv64-unknown-elf toolchain can compile rv32 programs if configured and built appropriately - particularly the multilib support.

When compiling your program what -march and -mabi are you referring to?

-march=rv32i -mabi=ilp32 or something else?

 

The OP was specifically asking for -march=rv64 and -mabi=ilp32, which is not a supported combination, at least not that I am aware off.

 

 

If the *XL bits can be used to support rv32 on rv64 (as seems to be suggested by the priv spec) then something will presumably need to change the *XL bit(s) before the rv32 program starts running?

 

Yeah, you’ll need to write a piece of firmware to set the bits.

If the 32bit application makes low-level calls, then those bits need to be set/reset depending on the environment.

For task switch they would need to be preserved, assuming the OS doesn’t keep track of the application’s nature.

I am still in dubio, and this is where a SW guy needs to provide their insights, what happens with callee saved registers.

If an RV64 is switched to RV32 mode does it still push the entire register? I assume not, from the previous discussion I learned that messes up the stack (pointer).

So that would imply that, when in RV32 mode, the upper 32bits of the register are not changed? Kind of like ‘ax’ versus ‘eax’ in i32?

 

Richard

[Tommy Murphy]

Yes - but that was just one of two possible options that they asked might be feasible to facilitate running rv32 code on rv64.

[Neel Gala]

On Thu, Apr 26, 2018 at 5:20 PM, Richard Herveille <richard....@roalogic.com> wrote:

 

 

On 26/04/2018, 13:43, "Tommy Murphy" <tommy_...@hotmail.com> wrote:

 

Bear in mind that the riscv64-unknown-elf toolchain can compile rv32 programs if configured and built appropriately - particularly the multilib support.

When compiling your program what -march and -mabi are you referring to?

-march=rv32i -mabi=ilp32 or something else?

 

The OP was specifically asking for -march=rv64 and -mabi=ilp32, which is not a supported combination, at least not that I am aware off.

 

 

If the *XL bits can be used to support rv32 on rv64 (as seems to be suggested by the priv spec) then something will presumably need to change the *XL bit(s) before the rv32 program starts running?

 

Yeah, you’ll need to write a piece of firmware to set the bits.

If the 32bit application makes low-level calls, then those bits need to be set/reset depending on the environment.

For task switch they would need to be preserved, assuming the OS doesn’t keep track of the application’s nature.

I am still in dubio, and this is where a SW guy needs to provide their insights, what happens with callee saved registers.

If an RV64 is switched to RV32 mode does it still push the entire register? I assume not, from the previous discussion I learned that messes up the stack (pointer).

So that would imply that, when in RV32 mode, the upper 32bits of the register are not changed? Kind of like ‘ax’ versus ‘eax’ in i32?

But the spec explicit says that the operands need to be sign-extended while updating the XLEN bit registers. Upper data bits will be lost.

 

 

Richard

 

On Thursday, 26 April 2018 12:24:29 UTC+1, Neel Gala wrote:

Just to confirm, this enhancement will allow to me compile an application using the riscv32-unknown-* toolchain and then run the binary on a 64-bit core with MXL/SXL/UXL set to 1. Am I right?

--

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

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/A140466D-44B5-4CFA-9468-5AC6153A6B9D%40roalogic.com.

[Richard Herveille]

 

 

On 26/04/2018, 16:46, "Neel Gala" <neel...@gmail.com> wrote:

 

On Thu, Apr 26, 2018 at 5:20 PM, Richard Herveille <richard....@roalogic.com> wrote:

 

 

On 26/04/2018, 13:43, "Tommy Murphy" <tommy_...@hotmail.com> wrote:

 

Bear in mind that the riscv64-unknown-elf toolchain can compile rv32 programs if configured and built appropriately - particularly the multilib support.

When compiling your program what -march and -mabi are you referring to?

-march=rv32i -mabi=ilp32 or something else?

 

The OP was specifically asking for -march=rv64 and -mabi=ilp32, which is not a supported combination, at least not that I am aware off.

 

 

If the *XL bits can be used to support rv32 on rv64 (as seems to be suggested by the priv spec) then something will presumably need to change the *XL bit(s) before the rv32 program starts running?

 

Yeah, you’ll need to write a piece of firmware to set the bits.

If the 32bit application makes low-level calls, then those bits need to be set/reset depending on the environment.

For task switch they would need to be preserved, assuming the OS doesn’t keep track of the application’s nature.

I am still in dubio, and this is where a SW guy needs to provide their insights, what happens with callee saved registers.

If an RV64 is switched to RV32 mode does it still push the entire register? I assume not, from the previous discussion I learned that messes up the stack (pointer).

So that would imply that, when in RV32 mode, the upper 32bits of the register are not changed? Kind of like ‘ax’ versus ‘eax’ in i32?

 

But the spec explicit says that the operands need to be sign-extended while updating the XLEN bit registers. Upper data bits will be lost.

 

Yes exactly. But unless I am missing something …

In RV32-mode a callee saved register will only push/pop the 32LSBs to/from the stack.

If all operands are sign extended then the MSBs will end up to be either all ‘0’ or ‘1’.

Thus when the RV32 routine returns the original register contents won’t be correct.

 

So

1. Either this is not intended for calling 32bit routines, but only for running 32bit applications in OS-es like Linux
2. Or all operands should ONLY work on/up to XLEN, which is 32bit for RV32(mode) and 64bit for RV64(mode)

 

I think (2) would be the nicest solution, but it has a hardware cost. I also believe that (2) is compatible with the specs as they currently are. The spec would need to specify that all operands operate at XLEN size only though.

 

Richard

 

 

 

Richard

 

On Thursday, 26 April 2018 12:24:29 UTC+1, Neel Gala wrote:

Just to confirm, this enhancement will allow to me compile an application using the riscv32-unknown-* toolchain and then run the binary on a 64-bit core with MXL/SXL/UXL set to 1. Am I right?

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to

sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit

https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/A140466D-44B5-4CFA-9468-5AC6153A6B9D%40roalogic.com.

[Stef O'Rear]

On Thu, Apr 26, 2018 at 1:25 PM, Richard Herveille
<richard....@roalogic.com> wrote:
> Yes exactly. But unless I am missing something …
>
> In RV32-mode a callee saved register will only push/pop the 32LSBs to/from
> the stack.
>
> If all operands are sign extended then the MSBs will end up to be either all
> ‘0’ or ‘1’.
>
> Thus when the RV32 routine returns the original register contents won’t be
> correct.
>
>
>
> So
>
> Either this is not intended for calling 32bit routines, but only for running
> 32bit applications in OS-es like Linux
> Or all operands should ONLY work on/up to XLEN, which is 32bit for
> RV32(mode) and 64bit for RV64(mode)

The UXL mechanism is intended to allow 32-bit and 64-bit processes to
coexist. UXL is only changed as part of a task switch which saved all
registers for the old task and loads all registes for the new task.

Mixing 32-bit and 64-bit routines in a completely transparent fashion
is not possible as the 32-bit and 64-bit code will disagree about
memory layout. (You will recall that "16-bit" Windows had 32-bit
segment:offset far pointers; the Windows thunking mechanism was only
possible because the pointer size did not change.) The details of MXL
handling are irrelevant to this impossibility.

> I think (2) would be the nicest solution, but it has a hardware cost. I also
> believe that (2) is compatible with the specs as they currently are. The
> spec would need to specify that all operands operate at XLEN size only
> though.

The current spec (
https://github.com/riscv/riscv-isa-manual/blob/master/src/machine.tex#L91-L94
) clearly specifies that the entire register is overwritten even when
operating in a narrower mode.

-s

[Michael Clark]

> On 26/04/2018, at 11:50 PM, Richard Herveille <richard....@roalogic.com> wrote:
>
> The OP was specifically asking for -march=rv64 and -mabi=ilp32, which is not a supported combination, at least not that I am aware off.

This will be a new ABI much like X32 on x86_64 and will need changes to GCC, newlib as well as glibc and the Linux kernel if it is to also be supported by Linux.

I believe it has been stated that if there is a serious demand for a 32-bit pointer ABI on RV64, then it will be implemented. I suspect the decision won’t be made casually as it effectively adds a completely new ABI which adds another quite large test dimension for the riscv tools.

While X32 on x86_64 benefits a lot from extra registers, an ILP32 ABI for RV64 would also be beneficial due to the reduction in memory bandwidth e.g. arrays of pointers and structures with pointer members get smaller. It should potentially be on the roadmap. It would have benefit for RV64 MCUs in terms of code and memory size.