On Sun, 20 Oct 2019 at 20:40, TheGag96 via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> Darn... Are there any plans at some point in the future to add a real -betterC sort of flag? It would be really really nice to be able to compile something like...
>
> import std.bitmanip : bitfields;
>
> struct Stuff {
>    mixin(bitfields!(
>          uint, "x",    2,
>          int,  "y",    3,
>          uint, "z",    2,
>          bool, "flag", 1));
> }
>
> extern(C) void main() {
>    Stuff x;
> }
>
> ...just as in DMD or LDC.

Saying that, if you can distil that into a test case with no dependencies (no imports) and gdc emits something that neither ldc or dmd does, then I should probably be notified about that in a bug report, as a newer version of the D language frontend won't necessarily fix it.

-- 
Iain

On Sunday, 20 October 2019 at 18:25:42 UTC, TheGag96 wrote:
> On Sunday, 20 October 2019 at 09:36:17 UTC, Johan Engelen wrote:
>> Did you try with LDC?
>> Just a wild guess but perhaps this triple will work: `-mtriple=armv6k-unknown-eabi`.
>>
>> -Johan
>
> I haven't yet, but I've been told also by someone else to try! It would certainly be nice to have a true -betterC going with this. Does LDC have equivalent flags for what devkitARM wants passed into GCC, like:
>
> -march=armv6k

-mtriple=armv6k-unknown-eabi
I am not sure about the "eabi".

> -mtune=mpcore

This is not strictly needed. (It's an optimization parameter)
Maybe "-mcpu=mpcore" sets the optimizer to optimize for that cpu.

> -mfloat-abi=hard

-float-abi=hard

> -mtp=soft
Don't know if we expose this option, but LDC by default seem to do the same as GCC's -mtp=soft:
https://d.godbolt.org/z/bmcRdI

> -mword-relocations

Don't know!

> -fomit-frame-pointer

This is more of a non-debug option, so not strictly needed. LDC's option is -frame-pointer=none (for newer LDC), or --disable-fp-elim=false (older and newer LDC).

> -ffunction-sections

-function-sections

LDC is a cross compiler by nature, but you'll have to build the runtime libraries yourself. But LDC contains an easy tool for just that! Read: https://wiki.dlang.org/Building_LDC_runtime_libraries

cheers,
 Johan

On Sunday, 20 October 2019 at 20:31:04 UTC, Johan wrote:
> (snip)

Awesome, I just might try to get LDC working with this...

On a different note, I'd really like a critique on a decision I made. Creating the bindings for libctru and citro3d was really tedious, partly because I made the decision to change every named enum from stuff like...

enum GPU_TEXTURE_WRAP_PARAM
{
  GPU_CLAMP_TO_EDGE   = 0x0, ///< Clamps to edge.
  GPU_CLAMP_TO_BORDER = 0x1, ///< Clamps to border.
  GPU_REPEAT          = 0x2, ///< Repeats texture.
  GPU_MIRRORED_REPEAT = 0x3, ///< Repeats with mirrored texture.
}

...to...

enum GPUTextureWrapParam
{
  clamp_to_edge   = 0x0, ///< Clamps to edge.
  clamp_to_border = 0x1, ///< Clamps to border.
  repeat          = 0x2, ///< Repeats texture.
  mirrored_repeat = 0x3  ///< Repeats with mirrored texture.
}

...in order to fit the D naming style, since the semantics for the enum was changing anyway. But of course, every struct must keep its old name... Is this alright? Should I add aliases for every struct for a better naming style, or maybe go back on my decision before, or...?

On Sun, Oct 20, 2019 at 11:40 PM TheGag96 via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Sunday, 20 October 2019 at 20:31:04 UTC, Johan wrote:
> > (snip)
>
> Awesome, I just might try to get LDC working with this...
>
> ...
> ...in order to fit the D naming style, since the semantics for
> the enum was changing anyway. But of course, every struct must
> keep its old name... Is this alright? Should I add aliases for
> every struct for a better naming style, or maybe go back on my
> decision before, or...?

If it is binding you should probably let it same as original code. I always try to make bindings as same as possible. It is much easier port existing code in original language. If I want to change interface or anything I made a new wrapper around that binding

On Sun, 20 Oct 2019 at 20:40, TheGag96 via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Sunday, 20 October 2019 at 15:27:35 UTC, Iain Buclaw wrote:
> > Great stuff!  Though I don't think you'll find much improvement in gdc 10 regarding switching off D features.  Backported patches to make gdc on parity with dmd as of April 2019 was done prior to the gdc 9 release.  I'm not aware of much more being done regarding that other than some extern(C) library functions being converted into templates, and the C main function being moved to a common location in D runtime (C main is not "compiled into" gdc unlike previous versions of dmd).
>
> Darn... Are there any plans at some point in the future to add a real -betterC sort of flag? It would be really really nice to be able to compile something like...
>
> import std.bitmanip : bitfields;
>
> struct Stuff {
>    mixin(bitfields!(
>          uint, "x",    2,
>          int,  "y",    3,
>          uint, "z",    2,
>          bool, "flag", 1));
> }
>
> extern(C) void main() {
>    Stuff x;
> }
>
> ...just as in DMD or LDC.

You can compile that with gdc-9 just fine.

$ cat test.d
import std.bitmanip : bitfields;

struct Stuff {
   mixin(bitfields!(
         uint, "x",    2,
         int,  "y",    3,
         uint, "z",    2,
         bool, "flag", 1));
}

extern(C) void main() {
   Stuff x;
   x.x = 1;
   x.y = 42;
   x.z = 4;
   x.flag = true;
   return;
}

$ gdc -v 2>&1 | grep version
gcc version 9.2.0 (GCC)

$ gdc -fno-druntime test.d

$ nm a.out
0000000000004028 B __bss_start
0000000000004028 b completed.7380
                 w __cxa_finalize@@GLIBC_2.2.5
0000000000001142 T _D4test5Stuff1xMFNaNbNdNiNfkZv
0000000000001125 T _D4test5Stuff1xMxFNaNbNdNiNfZk
0000000000001194 T _D4test5Stuff1yMFNaNbNdNiNfiZv
000000000000116a T _D4test5Stuff1yMxFNaNbNdNiNfZi
00000000000011df T _D4test5Stuff1zMFNaNbNdNiNfkZv
00000000000011bf T _D4test5Stuff1zMxFNaNbNdNiNfZk
000000000000121e T _D4test5Stuff4flagMFNaNbNdNiNfbZv
000000000000120a T _D4test5Stuff4flagMxFNaNbNdNiNfZb
0000000000002004 R _D4test5Stuff6__initZ
0000000000004018 D __data_start
0000000000004018 W data_start
0000000000001070 t deregister_tm_clones
00000000000010e0 t __do_global_dtors_aux
0000000000003e00 t __do_global_dtors_aux_fini_array_entry
0000000000004020 D __dso_handle
0000000000003e08 d _DYNAMIC
0000000000004028 D _edata
0000000000004030 B _end
0000000000001314 T _fini
0000000000001120 t frame_dummy
0000000000003df8 t __frame_dummy_init_array_entry
000000000000228c r __FRAME_END__
0000000000004000 d _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
0000000000002008 r __GNU_EH_FRAME_HDR
0000000000001000 t _init
0000000000003e00 t __init_array_end
0000000000003df8 t __init_array_start
0000000000002000 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
0000000000001310 T __libc_csu_fini
00000000000012b0 T __libc_csu_init
                 U __libc_start_main@@GLIBC_2.2.5
0000000000001259 T main
00000000000010a0 t register_tm_clones
0000000000001040 T _start
0000000000004028 D __TMC_END__

-- 
Iain

On Monday, 21 October 2019 at 19:03:00 UTC, Iain Buclaw wrote:
> (snip)

Yeah, I just learned you could do this not long after I posted - when I tried, I had a gdc from around the time of 9.0.1 instead of 9.2, so I just had to rebuild. I'm currently attempting to get a devkitARM based off of 9.2 going since I thought it'd be simple - that may go a long way to making no-runtime/betterC work better!