<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 November 2015 at 00:40, Manu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3 November 2015 at 18:36, Joakim via Digitalmars-d<br>
<div><div class="h5"><<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
> On Tuesday, 3 November 2015 at 07:30:44 UTC, Johannes Pfau wrote:<br>
>><br>
>> Am Tue, 3 Nov 2015 09:16:47 +1000<br>
>> schrieb Manu via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>>:<br>
>><br>
>>> I have a samples directory which it would be theoretically possible to<br>
>>> run and see that they don't crash as part of a test run. Also, I'd like to<br>
>>> annotate my whole engine quite comprehensively with unittests. It's<br>
>>> something that I'm keen to work on, and then it further helps to assure<br>
>>> those toolchains remain working.<br>
>><br>
>><br>
>> But how exactly would you run these? All CI machines are x86_64. I guess<br>
>> emulators could be a possibility as long as they run headless. We'd need<br>
>> some way to get feedback from the emulator though (test passed/failed). If<br>
>> you're talking about running tests on the x86_64 architecture that should be<br>
>> easy.<br>
><br>
><br>
> There's a Dreamcast emulator for Android/ARM:<br>
><br>
> <a href="https://github.com/reicast/reicast-emulator" rel="noreferrer" target="_blank">https://github.com/reicast/reicast-emulator</a><br>
><br>
> You could run it inside the Android emulator on Travis: :)<br>
><br>
> <a href="http://docs.travis-ci.com/user/languages/android/" rel="noreferrer" target="_blank">http://docs.travis-ci.com/user/languages/android/</a><br>
><br>
> I'm sure their servers can handle an emulator of a 200 MHz MIPS core with 16<br>
> MB of RAM running inside an ARM emulator. ;)<br>
<br>
</div></div>For the record, I was mostly joking about Dreamcast ;) ... while I did<br>
support it actively some years back, I haven't built that code in a<br>
while. It would be a lot of fun to get it working again though :P<br>
Incidentally, there's a GCC dev that's been committing SIMD<br>
optimisations for the SH4 (Dreamcast) backend recently. He's obviously<br>
having some fun making all the vector intrinsics work with the DC<br>
hardware.<br>
Latest GCC is the best Dreamcast compiler we've ever had!<br>
</blockquote></div><br></div><div class="gmail_extra">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.  ;-)<br><br></div><div class="gmail_extra">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).<br></div></div>