On 2 November 2015 at 04:17, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Sun, 1 Nov 2015 11:33:21 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>
>> If people find this to be an interesting project, and I do take some
>> time to do this port, what I'd really love is to work together with
>> some of the niche platform support guys and use it to stress test
>> toolchains for various platforms. I'd also like help from guys like
>> Johannes to make regularly released builds of some console
>> cross-compilers available so that it can keep on building.
>> The CI of this project for those platforms would more-or-less verify
>> that the toolchains and druntime+friends are working.
>
> Sounds like a great idea!
>
> I can certainly build the GDC toolchains*. But I guess the first thing you'll need if you want to use Dreamcast, NDS and other low memory systems is a @nogc druntime port? I had a look at this some time ago and there's some work to be done until we can build a druntime completely without GC.

Awesome! Your support on this is really encouraging. Almost all consoles are typically targeted by GCC. PS4 uses Clang officially, but I'm sure GCC works just as well.

Easiest to start with some of the bigger systems. I think another benefit of this project may be that building for the smaller systems will start to reveal binary size issues, and perhaps we can use it as a vessel to drive some improvements in that area. Binary size is something that's been really irk-ing me for years.

What implicitly linked parts of druntime are not @nogc?
I have no good reason to say that @nogc should be an absolute
requirement... it is almost certainly preferable to many gamedevs so
it would be nice to support it, but GC should be available if the
developer wants it... I'm not sure what cost that comes at in terms of
binary size. Runtime memory is a matter for the developer, they know
the compromise they are making if they opt to use the GC.


> or better: also provide build scripts. We now use docker.io containers to build the binary GDC toolchains. Building a toolchain with the latest GDC version is as simple as running one docker command:
>
> docker run
> -v ~/shared-dir/:/home/build/shared #results will be saved here
> -t jpf91/build-gdc /usr/bin/build-gdc build
> --toolchain=x86_64-w64-mingw32/gcc-5/x86_64-w64-mingw32
>
> It should be easy enough to add support for console toolchain build scripts.

Awesome, and that would just be run along with the rest of the CI when producing toolchains? Reliable binary downloads available in known places? Even the presence of these toolchains (whether people use them or not) will inspire some confidence in gamedev's that D means business in gamedev. They are more likely to give D a shot if they know that toolchains are available should ports need to be made at some later stage.

On 2 November 2015 at 05:27, Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2015-11-01 02:33, Manu via Digitalmars-d wrote:
>
>> I have been thinking about full-scale porting to D
>
>
> You could enhance DStep [1] to handle complete source code and not only headers.

I'll give it a shot... see how close it gets me.
It's almost C code (C with light internal use of classes), so it
should port really easily.

On 2015-11-02 05:24, Manu via Digitalmars-d wrote:

> I'll give it a shot... see how close it gets me.
> It's almost C code (C with light internal use of classes), so it
> should port really easily.

DStep currently only supports C code, not almost C code :).

-- 
/Jacob Carlborg

On 2 November 2015 at 17:55, Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2015-11-02 05:24, Manu via Digitalmars-d wrote:
>
>> I'll give it a shot... see how close it gets me.
>> It's almost C code (C with light internal use of classes), so it
>> should port really easily.
>
>
> DStep currently only supports C code, not almost C code :).

It'll probably get through 95% of the files... actually, I use enum aswell, is that supported?

On Sunday, 1 November 2015 at 17:07:17 UTC, Joseph Rushton Wakeling wrote:
> Wow.  That sounds like it could have uses far beyond games -- I'm thinking Erlang-style hot-swapping of components of super-high-uptime (web) services ...

For D1 there was DDL http://www.dsource.org/projects/ddl/wiki/AboutDDL that could load and relocate object files as dynamic libraries.

On 2015-11-02 09:47, Manu via Digitalmars-d wrote:

> It'll probably get through 95% of the files... actually, I use enum
> aswell, is that supported?

Yes. You can get a rough idea of what's supported by looking in the "test_files" directory.

-- 
/Jacob Carlborg

Am Mon, 2 Nov 2015 14:24:18 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 2 November 2015 at 05:27, Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > On 2015-11-01 02:33, Manu via Digitalmars-d wrote:
> > 
> >> I have been thinking about full-scale porting to D
> >
> >
> > You could enhance DStep [1] to handle complete source code and not only headers.
> 
> I'll give it a shot... see how close it gets me.
> It's almost C code (C with light internal use of classes), so it
> should port really easily.

And if dstep doesn't work maybe the DDMD magicport tool could be useful.

Am Mon, 2 Nov 2015 14:22:33 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 2 November 2015 at 04:17, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > Sounds like a great idea!
> >
> > I can certainly build the GDC toolchains*. But I guess the first thing you'll need if you want to use Dreamcast, NDS and other low memory systems is a @nogc druntime port? I had a look at this some time ago and there's some work to be done until we can build a druntime completely without GC.
> 
> Awesome! Your support on this is really encouraging. Almost all consoles are typically targeted by GCC. PS4 uses Clang officially, but I'm sure GCC works just as well.
> 
> Easiest to start with some of the bigger systems. I think another benefit of this project may be that building for the smaller systems will start to reveal binary size issues, and perhaps we can use it as a vessel to drive some improvements in that area. Binary size is something that's been really irk-ing me for years.
> 
> What implicitly linked parts of druntime are not @nogc?

The usual stuff: AA handling, array concatenation etc. It's not a problem as long as you don't use these. But to build a druntime without the GC we'd have to find all these cases and place them in a version(GCAvailable) block. If we build the GC stub or the GC we don't have this problem.

Then there's some Exception handling related stuff: IIRC the backtrace data is allocated using the GC and I think core.demangle uses the GC as well. Probably not a big issue.

Some higher level stuff such as Threads and Fibers also have special GC integration. And then there are probably some 'toString' methods every so often.

> I have no good reason to say that @nogc should be an absolute requirement... it is almost certainly preferable to many gamedevs so it would be nice to support it, but GC should be available if the developer wants it... I'm not sure what cost that comes at in terms of binary size. Runtime memory is a matter for the developer, they know the compromise they are making if they opt to use the GC.
> 

Maybe I'm a little to pessimistic about the GC ;-) I'm just not sure if it can deal with low-memory situations such as if you've only got 16MB memory total. And IIRC the GC always preallocates some blocks. So even if we never use the GC it might steal some memory. OTOH it would likely be not much work to adjust this allocation size.

> 
> > or better: also provide build scripts. We now use docker.io containers to build the binary GDC toolchains. Building a toolchain with the latest GDC version is as simple as running one docker command:
> >
> > docker run
> > -v ~/shared-dir/:/home/build/shared #results will be saved here
> > -t jpf91/build-gdc /usr/bin/build-gdc build
> > --toolchain=x86_64-w64-mingw32/gcc-5/x86_64-w64-mingw32
> >
> > It should be easy enough to add support for console toolchain build scripts.
> 
> Awesome, and that would just be run along with the rest of the CI when producing toolchains? Reliable binary downloads available in known places?

These toolchains would be built like all other toolchains on gdcproject.org/downloads and would also be listed on that page.

We currently do not have a CI setup for all these toolchains. Building the windows variant of a toolchain can take up to an hour (on my i5 notebook). Building all combinations for every commit on CI would be very costly.

I hope to integrate all linux hosted toolchains with Travis-CI
(as a bonus we can probably extract nightly builds). It's a bit of a
PITA as building requires quite some disk space (10GB+ required,
semaphoreCI offers only 5GB). And I have to avoid these stupid
10 minute command timeout on travis-ci.

Let's see if this works:
https://travis-ci.org/jpf91/GDC/builds/88839377
(seems to be quite slow though...)

OTOH even if we manage to integrate CI this tests only that the code builds. I don't think runtime testing is possible in some easy way.

> Even the presence of these toolchains (whether people use them
> or not) will inspire some confidence in gamedev's that D means
> business in gamedev. They are more likely to give D a shot if they
> know that toolchains are available should ports need to be made at
> some later stage.

On 3 November 2015 at 04:38, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Mon, 2 Nov 2015 14:22:33 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>
> Maybe I'm a little to pessimistic about the GC ;-) I'm just not sure if it can deal with low-memory situations such as if you've only got 16MB memory total. And IIRC the GC always preallocates some blocks. So even if we never use the GC it might steal some memory. OTOH it would likely be not much work to adjust this allocation size.

Perhaps the pre-allocation could become an API which the user might prefer not to call?


> Let's see if this works:
> https://travis-ci.org/jpf91/GDC/builds/88839377
> (seems to be quite slow though...)
>
> OTOH even if we manage to integrate CI this tests only that the code builds. I don't think runtime testing is possible in some easy way.

I have a samples directory which it would be theoretically possible to run and see that they don't crash as part of a test run. Also, I'd like to annotate my whole engine quite comprehensively with unittests. It's something that I'm keen to work on, and then it further helps to assure those toolchains remain working.

On Sunday, 1 November 2015 at 02:36:16 UTC, Manu wrote:
> ...
> Does it support Dreamcast? :P

I don't know if you are being serious here but if yes... what's the catch with Dreamcast? I mean this is a Fan thing or what?

PS: I'm asking this because I used to code for GBA a long time ago but just for fun and hobby!

Matheus.