On 4 November 2015 at 00:40, Manu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> On 3 November 2015 at 18:36, Joakim via Digitalmars-d > <digitalmars-d@puremagic.com> wrote: > > On Tuesday, 3 November 2015 at 07:30:44 UTC, Johannes Pfau wrote: > >> > >> Am Tue, 3 Nov 2015 09:16:47 +1000 > >> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: > >> > >>> 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. > >> > >> > >> But how exactly would you run these? All CI machines are x86_64. I guess > >> emulators could be a possibility as long as they run headless. We'd need > >> some way to get feedback from the emulator though (test passed/failed). > If > >> you're talking about running tests on the x86_64 architecture that > should be > >> easy. > > > > > > There's a Dreamcast emulator for Android/ARM: > > > > https://github.com/reicast/reicast-emulator > > > > You could run it inside the Android emulator on Travis: :) > > > > http://docs.travis-ci.com/user/languages/android/ > > > > I'm sure their servers can handle an emulator of a 200 MHz MIPS core > with 16 > > MB of RAM running inside an ARM emulator. ;) > > For the record, I was mostly joking about Dreamcast ;) ... while I did > support it actively some years back, I haven't built that code in a > while. It would be a lot of fun to get it working again though :P > Incidentally, there's a GCC dev that's been committing SIMD > optimisations for the SH4 (Dreamcast) backend recently. He's obviously > having some fun making all the vector intrinsics work with the DC > hardware. > Latest GCC is the best Dreamcast compiler we've ever had! > I'm aware of this, not because I take an interest, but because I was cc'd into discussion when they discovered a C++ regression that was seen by comparing the md5sum of (D frontend) interpret.c sources between 2nd and 3rd generation bootstrapped builds. ;-) If you don't understand why, that's because this file contains all frontend const folding routines for every operation on every basic type supported in D, and then some. So itself becomes a good stress test of a compiler's codegen ability (or in this case, the ability to produce consistent code).