Is gdc using the d-based front end in a stable state?

The context for the question is that I've made some changes to the front end and would like to see if it was possible use it with the gcc backend (gcc has good embedded support).

On Sunday, 11 October 2020 at 14:22:14 UTC, Ola Fosheim Grøstad wrote:
> Is gdc using the d-based front end in a stable state?

Ok, that wasn't clear. I meant:

Is gdc, the version using the d-based front end, in a stable state?

:)

On Sunday, 11 October 2020 at 14:42:50 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 11 October 2020 at 14:22:14 UTC, Ola Fosheim Grøstad wrote:
>> Is gdc using the d-based front end in a stable state?
>
> Ok, that wasn't clear. I meant:
>
> Is gdc, the version using the d-based front end, in a stable state?
>
> :)

Relatively speaking, yes.  It's not inherently unstable because its written in D, but the dmd developers occassionally break the bootstrap in obscure ways, as of recent it's been refactoring imports that have caused some latent template and symbol resolver bugs to be exposed.

On Sunday, 11 October 2020 at 20:17:16 UTC, Iain Buclaw wrote:
> Relatively speaking, yes.  It's not inherently unstable because its written in D, but the dmd developers occassionally break the bootstrap in obscure ways, as of recent it's been refactoring imports that have caused some latent template and symbol resolver bugs to be exposed.

Are you tracking the "stable" branch, or the "master" branch of DMD?

I assume "stable" is the last release of DMD?

On Monday, 12 October 2020 at 11:07:55 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 11 October 2020 at 20:17:16 UTC, Iain Buclaw wrote:
>> Relatively speaking, yes.  It's not inherently unstable because its written in D, but the dmd developers occassionally break the bootstrap in obscure ways, as of recent it's been refactoring imports that have caused some latent template and symbol resolver bugs to be exposed.
>
> Are you tracking the "stable" branch, or the "master" branch of DMD?
>
> I assume "stable" is the last release of DMD?

I'm tracking the "master" branch of DMD, as the "merge master into stable" commits are huge and tend to come with many implementation regressions.

Saying that, it has been since 2.093.0-devel since I last did a sync, and I've only just recently fixed dmd master (again).

https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/users/ibuclaw/heads/gdc

Based off of dmd v2.093.1-686-g3a55c54a8 (as of writing, the current HEAD). Bootstrapped using gdc-9.3.1, and all tests are passing on x86_64-linux-gnu, but that may not be a good indication that things are fine, and more testing on other architectures would be welcome.

Unless your knowledge of git better than mine, and you have a cleverly crafted git clone command, the best way I know of fetching the sources is in the following way:

git init
git remote add users/ibuclaw git://gcc.gnu.org/git/gcc.git
git config --replace-all remote.users/ibuclaw.fetch "+refs/users/ibuclaw/heads/*:refs/remotes/users/ibuclaw/*"
git fetch users/ibuclaw
git checkout -b gdc-mainline users/ibuclaw/gdc

The assumption is you already know how to build gcc from here.

On Monday, 12 October 2020 at 17:26:22 UTC, Iain Buclaw wrote:
> I'm tracking the "master" branch of DMD, as the "merge master into stable" commits are huge and tend to come with many implementation regressions.

Maybe it is better to wait for an official gdc/gcc release then.

> git init
> git remote add users/ibuclaw git://gcc.gnu.org/git/gcc.git
> git config --replace-all remote.users/ibuclaw.fetch "+refs/users/ibuclaw/heads/*:refs/remotes/users/ibuclaw/*"
> git fetch users/ibuclaw
> git checkout -b gdc-mainline users/ibuclaw/gdc
>
> The assumption is you already know how to build gcc from here.

Ok, thanks. I will give it a spin in a few days and see what happens. What I'd like to try out is AVR/Arduino as a target, but I see that avr-gcc is a separate project. Maybe not compatible with gdc.

Expressions should default to 16 bit integers for performance, but that only affects the standard library I think. So it could work with the better-C subset… Although for a start one could use 32 bit (with slow performance). Actually, I would be excited just to see a LED blinking... :P

On Monday, 12 October 2020 at 18:03:39 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 12 October 2020 at 17:26:22 UTC, Iain Buclaw wrote:
>> I'm tracking the "master" branch of DMD, as the "merge master into stable" commits are huge and tend to come with many implementation regressions.
>
> Maybe it is better to wait for an official gdc/gcc release then.
>

I won't be pushing anything unless everything passes, so no need to worry about that.

>> git init
>> git remote add users/ibuclaw git://gcc.gnu.org/git/gcc.git
>> git config --replace-all remote.users/ibuclaw.fetch "+refs/users/ibuclaw/heads/*:refs/remotes/users/ibuclaw/*"
>> git fetch users/ibuclaw
>> git checkout -b gdc-mainline users/ibuclaw/gdc
>>
>> The assumption is you already know how to build gcc from here.
>
> Ok, thanks. I will give it a spin in a few days and see what happens. What I'd like to try out is AVR/Arduino as a target, but I see that avr-gcc is a separate project. Maybe not compatible with gdc.
>
> Expressions should default to 16 bit integers for performance, but that only affects the standard library I think. So it could work with the better-C subset… Although for a start one could use 32 bit (with slow performance). Actually, I would be excited just to see a LED blinking... :P

I've just given it a whirl using avr-gcc and simulavr (from ubuntu focal), and a simplified example program from here http://www.nongnu.org/simulavr/simple_ex.html.

    # Also set AS_FOR_TARGET and others just to be sure...
    $ ../configure --prefix=/usr/lib --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-language=d --target=avr --with-as=/usr/lib/avr/bin/as --with-ld=/usr/lib/avr/bin/ld
    $ make -j$(nproc)
    $ DESTDIR=$PWD/avr-gdc make install -j$(nproc)

    $ echo 'module object;' > object.d
    $ echo 'module core.volatile;
nothrow: @safe: @nogc:
void volatileStore(ubyte * ptr, ubyte  value);
ubyte volatileLoad(ubyte * ptr);
' > volatile.d
    $ echo 'module main;
import core.volatile;
// This port corresponds to the "-W 0x20,-" command line option.
enum stdout = cast(ubyte *)0x20;
// This port corresponds to the "-R 0x22,-" command line option.
enum stdin = cast(ubyte *)0x22;
// Poll the specified string out the debug port.
void debug_puts(const(char)[] str) {
    foreach (c; str)
        volatileStore(stdout, c);
}
extern (C) int main() {
    debug_puts("\nHello " ~ __VENDOR__ ~ " " ~ __VERSION__.stringof ~ " on AVR\n\n");
    return 0;
}
' > main.d

    # Extra -L and -B wouldn't be necessary if I installed it in the system, or
    # avr-libc was installed in same directory.
    $ ./avr-gdc/usr/bin/avr-gdc -fno-druntime main.d volatile.d -O2 -mmcu=attiny2313 -L/usr/lib/avr/lib -L/usr/lib/avr/lib/avr25/tiny-stack -B/usr/lib/avr/lib/avr25/tiny-stack

    $ simulavr -d attiny2313 -f a.out -W 0x20,- -R 0x22,- -T exit

Hello GNU D 2094L on AVR

SystemClock::Endless stopped
number of cpu cycles simulated: 442

On Monday, 12 October 2020 at 23:59:15 UTC, Iain Buclaw wrote:
> I won't be pushing anything unless everything passes, so no need to worry about that.

May I ask here, is there any chance to include GDMD wrapper in GCC?

On Tuesday, 13 October 2020 at 01:42:55 UTC, Boris Carvajal wrote:
> On Monday, 12 October 2020 at 23:59:15 UTC, Iain Buclaw wrote:
>> I won't be pushing anything unless everything passes, so no need to worry about that.
>
> May I ask here, is there any chance to include GDMD wrapper in GCC?

Only if it was written in D.  Someone has tried this in the past (there's a branch in the github repo), and I have a POC somewhere that reads in dmd/cli.d at CTFE and generates code to tokenize arguments read from the command-line, but I don't consider the lack of a blocker given dmd command-line is less than intuitive and x86-centric.  There are far too many higher priority things to tackle with my limited time.

On Monday, 12 October 2020 at 23:59:15 UTC, Iain Buclaw wrote:
> I won't be pushing anything unless everything passes, so no need to worry about that.

Good to know. :-)

> I've just given it a whirl using avr-gcc and simulavr (from ubuntu focal), and a simplified example program from here http://www.nongnu.org/simulavr/simple_ex.html.
[...]
>     $ simulavr -d attiny2313 -f a.out -W 0x20,- -R 0x22,- -T exit
>
> Hello GNU D 2094L on AVR
>
> SystemClock::Endless stopped
> number of cpu cycles simulated: 442

Cool! Thanks for providing the full output, makes it easier to get started.
I'll certainly give this a spin.