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

Hesham Almatary heshamelmatary at gmail.com
Mon Oct 30 23:33:13 UTC 2017


On Tue, Oct 31, 2017 at 2:32 AM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> 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. :)
>
Thanks a lot! Now the problem is fixed. New patches are submitted.

> --joel
>
>
>> chris
>
>
>
> --
> Hesham
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
>



-- 
Hesham


More information about the devel mailing list