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

[Joel Sherrill]

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

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
should
> 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. :)

--joel


> chris



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