Re: gdc for rv32&64
On Wednesday, 18 August 2021 at 08:09:36 UTC, Iain Buclaw wrote:
On Wednesday, 18 August 2021 at 07:08:09 UTC, Mahdi wrote:
A helloworld program on the X86_64-pc-linux-gnu platform
contains 40 lines of assembly code or on the ARM
(aarch64-linux-gnu) platform only 34 lines of assembly code,
but on the risc-v(riscv64-unknow-gnu-linux) platform contains
871 lines of code on the explore.dgnu.org site!
I'm concerned that this will affect the performance of the
risc-v platform.
A Phobos helloworld is over 1000 lines of assembly on both
x86_64 and ARM64. My guess is that Compiler Explorer isn't
smart enough to filter RISC-V assembly in the same way as ARM
or X86.
This can be confirmed locally with objdump, to reveal a bunch of
code that's filtered out by default:
```
$ cat hello.d
void main() {
import std.stdio : writeln;
writeln("Hello, world!");
}
$ gdc hello.d
$ objdump -dwr --no-show-raw-insn a.out | grep -m1 isValidDchar |
ddemangle
3179a: call 6b870 std.utf.isValidDchar(dchar)>
```
You can also confirm it the Compiler Explorer by opening the
Filter menu, below the compiler selection and "Compiler
options..." input, and unchecking the 'Directives' filter.
Re: gdc for rv32&64
On Wednesday, 18 August 2021 at 07:08:09 UTC, Mahdi wrote: On Tuesday, 17 August 2021 at 20:39:29 UTC, max haughton wrote: 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. A helloworld program on the X86_64-pc-linux-gnu platform contains 40 lines of assembly code or on the ARM (aarch64-linux-gnu) platform only 34 lines of assembly code, but on the risc-v(riscv64-unknow-gnu-linux) platform contains 871 lines of code on the explore.dgnu.org site! I'm concerned that this will affect the performance of the risc-v platform. A Phobos helloworld is over 1000 lines of assembly on both x86_64 and ARM64. My guess is that Compiler Explorer isn't smart enough to filter RISC-V assembly in the same way as ARM or X86.
Re: gdc for rv32&64
On Tuesday, 17 August 2021 at 20:39:29 UTC, max haughton wrote: 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. A helloworld program on the X86_64-pc-linux-gnu platform contains 40 lines of assembly code or on the ARM (aarch64-linux-gnu) platform only 34 lines of assembly code, but on the risc-v(riscv64-unknow-gnu-linux) platform contains 871 lines of code on the explore.dgnu.org site! I'm concerned that this will affect the performance of the risc-v platform.
Re: gdc for rv32&64
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.
Re: gdc for rv32&64
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](https://github.com/hmmdyl/LWDR/blob/d55a39d028942f0eb1582d473317f89030995703/source/rtoslink.d#L14-L34), 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?
Re: gdc for rv32&64
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](https://github.com/gcc-mirror/gcc/blob/91292490d573f9f9e4f162d6d8c693a969197f2d/contrib/config-list.mk#L32-L105), 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](https://github.com/hmmdyl/LWDR/blob/d55a39d028942f0eb1582d473317f89030995703/source/rtoslink.d#L14-L34), 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.
Re: gdc for rv32&64
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](https://github.com/gcc-mirror/gcc/blob/91292490d573f9f9e4f162d6d8c693a969197f2d/contrib/config-list.mk#L32-L105), 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.
Re: gdc for rv32&64
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](https://github.com/gcc-mirror/gcc/blob/91292490d573f9f9e4f162d6d8c693a969197f2d/contrib/config-list.mk#L32-L105), 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.
Re: gdc for rv32&64
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.
Re: gdc for rv32&64
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
Re: gdc for rv32&64
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.
Re: gdc for rv32&64
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.
