[PATCH 1/4] cpukit: RISC-V - make riscv32 code work for riscv64

Joel Sherrill joel at rtems.org
Mon Oct 30 15:32:05 UTC 2017

On Oct 30, 2017 10:16 AM, "Hesham Almatary" <heshamelmatary at gmail.com>

On Mon, Oct 30, 2017 at 3:48 PM, Chris Johns <chrisj at rtems.org> wrote:
> On 29/10/2017 16:59, Hesham Almatary wrote:
>> On Fri, Oct 27, 2017 at 8:49 PM, Hesham Almatary
>> <heshamelmatary at gmail.com> wrote:
>>> * Use #ifdefs for 32/64 bit code
>>> * Use unsigned long which is 32-bit on riscv32 and 64-bit on riscv64
(register size)
>>> * Move the code to a new shared riscv folder to be shared with riscv64
>>> * Symlink riscv -> riscv32
>>> * Symlink riscv -> riscv64
>> I am wondering if the main idea of sharing (speicifcally having sym
>> links) riscv code between riscv32 and riscv64 is fine.
> Symlinks are not portable across host operating systems, ie Windows. We
> avoid them.
> Shared code can be placed in libcpu. Is this a viable option?
I thought of this but haven't found a similar use case (shared
architecture code). All of the code there is for different CPU
families. Furthermore, there is this convention in Makefiles/RTEMS
tree where it should find a directory for [cpu_name] (where [cpu_name]
is normally the same as -> [cpu_name]tems4.12). This doesn't work for
shared riscv code (i.e. it can not be placed riscv32 or riscv64) I
think. If you've other suggestions for this issue please let me know.

There was a use case for this with a long dead port. The m4 macro that sets
RTEMS_CPU has the potential to transform the target on the command line to
something else.

At least that's what I recall from the depths of my memories without
looking at the source code. :)


> chris

devel mailing list
devel at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20171030/beed9f4f/attachment-0002.html>

More information about the devel mailing list