Jump to page: 1 2
Thread overview
gdc for rv32&64
Aug 15, 2021
Mahdi
Aug 15, 2021
max haughton
Aug 15, 2021
Mahdi
Aug 15, 2021
max haughton
Aug 16, 2021
Mahdi
Aug 16, 2021
Iain Buclaw
Aug 16, 2021
Mahdi
Aug 16, 2021
Iain Buclaw
Aug 17, 2021
Mahdi
Aug 17, 2021
max haughton
Aug 18, 2021
Mahdi
Aug 18, 2021
Iain Buclaw
Aug 23, 2021
jfondren
August 15, 2021

Hi Iain Buclaw, we appreciate your efforts in the d for the gnu ecosystem.
but what is the status of gdc for risc-v architecture, especially newlib?

August 15, 2021

On Sunday, 15 August 2021 at 15:03:26 UTC, Mahdi wrote:

>

Hi Iain Buclaw, we appreciate your efforts in the d for the gnu ecosystem.
but what is the status of gdc for risc-v architecture, especially newlib?

explore.dgnu.org

Have a play with that, RISC-V should work perfectly fine for low level things like MCUs. Now, as for druntime and Phobos I'm not sure, you'll probably have to look at the source code.

August 15, 2021

On Sunday, 15 August 2021 at 17:22:28 UTC, max haughton wrote:

>

On Sunday, 15 August 2021 at 15:03:26 UTC, Mahdi wrote:

>

Hi Iain Buclaw, we appreciate your efforts in the d for the gnu ecosystem.
but what is the status of gdc for risc-v architecture, especially newlib?

explore.dgnu.org

Have a play with that, RISC-V should work perfectly fine for low level things like MCUs. Now, as for druntime and Phobos I'm not sure, you'll probably have to look at the source code.

Thanks Max, I played with explore.dgnu.org and it doesn't seem to have a problem with risc-v64&32-linux-gnu, but unfortunately it still doesn't support riscv64-elf target.
This target (elf) is much more suitable for writing metal-bare or operation system goals.

August 15, 2021

On Sunday, 15 August 2021 at 19:42:11 UTC, Mahdi wrote:

>

On Sunday, 15 August 2021 at 17:22:28 UTC, max haughton wrote:

>

On Sunday, 15 August 2021 at 15:03:26 UTC, Mahdi wrote:

>

Hi Iain Buclaw, we appreciate your efforts in the d for the gnu ecosystem.
but what is the status of gdc for risc-v architecture, especially newlib?

explore.dgnu.org

Have a play with that, RISC-V should work perfectly fine for low level things like MCUs. Now, as for druntime and Phobos I'm not sure, you'll probably have to look at the source code.

Thanks Max, I played with explore.dgnu.org and it doesn't seem to have a problem with risc-v64&32-linux-gnu, but unfortunately it still doesn't support riscv64-elf target.
This target (elf) is much more suitable for writing metal-bare or operation system goals.

By elf target you mean that it doesn't assume the existence of Linux APIs? What's the difference? It will be outputting an elf binary

August 16, 2021

On Sunday, 15 August 2021 at 20:11:23 UTC, max haughton wrote:

>

By elf target you mean that it doesn't assume the existence of Linux APIs? What's the difference? It will be outputting an elf binary

I don't know, so far I have worked on each C target with riscv64-unknown-elf-gcc,
So far I have never worked with any bare-metal target with riscv64-linux-gnu-gcc.

August 16, 2021

On Sunday, 15 August 2021 at 19:42:11 UTC, Mahdi wrote:

>

On Sunday, 15 August 2021 at 17:22:28 UTC, max haughton wrote:

>

On Sunday, 15 August 2021 at 15:03:26 UTC, Mahdi wrote:

>

Hi Iain Buclaw, we appreciate your efforts in the d for the gnu ecosystem.
but what is the status of gdc for risc-v architecture, especially newlib?

explore.dgnu.org

Have a play with that, RISC-V should work perfectly fine for low level things like MCUs. Now, as for druntime and Phobos I'm not sure, you'll probably have to look at the source code.

Thanks Max, I played with explore.dgnu.org and it doesn't seem to have a problem with risc-v64&32-linux-gnu, but unfortunately it still doesn't support riscv64-elf target.
This target (elf) is much more suitable for writing metal-bare or operation system goals.

The list of targets on that site is only what's present in contrib/config-list.mk, which is just a bunch of configurations that try to cover the broadest test vectors of the compiler back-end, and is in no way the full range of supported targets of GDC.

There is no difference between the -linux and -elf sub-targets of RISC-V, other than one you can build Phobos with, and the other you can't.

As for Newlib, the predefined version condition exists (but only for Cygwin), but no one has yet ported Druntime to Newlib.

It might make sense to assume that Newlib will always be available on ELF/Fuchsia/RTEMS, but I haven't seen the need to build either Druntime/Phobos for any of the bare-metal targets, as you'll more likely be providing your own minimal Druntime, or using any of the existing ones, such as Minlibd or LWDR.

August 16, 2021

On Monday, 16 August 2021 at 08:43:40 UTC, Iain Buclaw wrote:

>

The list of targets on that site is only what's present in contrib/config-list.mk, which is just a bunch of configurations that try to cover the broadest test vectors of the compiler back-end, and is in no way the full range of supported targets of GDC.

[...]

Very good! If LWDR works on risc-v, it would be great. I thought it only works on ARM targets.

August 16, 2021

On Monday, 16 August 2021 at 09:28:41 UTC, Mahdi wrote:

>

On Monday, 16 August 2021 at 08:43:40 UTC, Iain Buclaw wrote:

>

The list of targets on that site is only what's present in contrib/config-list.mk, which is just a bunch of configurations that try to cover the broadest test vectors of the compiler back-end, and is in no way the full range of supported targets of GDC.

[...]

Very good! If LWDR works on risc-v, it would be great. I thought it only works on ARM targets.

There's nothing specifically tied to ARM in LWDR per-say. Maybe that'll change once exception support gets added (ARM EABI unwinder follows a different ABI), but I'm sure that can be coordinated with the maintainer to ensure both ARM EABI and Itanium can be toggled with a version flag.

The only prerequisite for LWDR I am aware of is that you must provide implementations for these helper functions, which would just wrap around Newlib in your case. Whether the wrapper is in C or D doesn't matter. The only difference is that you'll have to write out the extern(C) bindings yourself if in D.

August 17, 2021

On Monday, 16 August 2021 at 10:05:08 UTC, Iain Buclaw wrote:

>

On Monday, 16 August 2021 at 09:28:41 UTC, Mahdi wrote:

>

[...]

There's nothing specifically tied to ARM in LWDR per-say. Maybe that'll change once exception support gets added (ARM EABI unwinder follows a different ABI), but I'm sure that can be coordinated with the maintainer to ensure both ARM EABI and Itanium can be toggled with a version flag.

The only prerequisite for LWDR I am aware of is that you must provide implementations for these helper functions, which would just wrap around Newlib in your case. Whether the wrapper is in C or D doesn't matter. The only difference is that you'll have to write out the extern(C) bindings yourself if in D.

Why does a simple or empty Hello program generate a lot of assembly output for the risc-v architecture, but not for the ARM and X86 architectures?

August 17, 2021

On Tuesday, 17 August 2021 at 18:39:27 UTC, Mahdi wrote:

>

On Monday, 16 August 2021 at 10:05:08 UTC, Iain Buclaw wrote:

>

[...]

Why does a simple or empty Hello program generate a lot of assembly output for the risc-v architecture, but not for the ARM and X86 architectures?

Need an example.

« First   ‹ Prev
1 2