Thread overview
Non-x86 targets for DMD
May 17
Kagamin
6 days ago
solidstate1991
5 days ago
Stefan Koch
2 days ago
solidstate1991
April 14
Since the backend is no longer restrained by Symantec licenses, there's no reason why there should be only be x86 and amd64 CPU support even if GDC and LDC already have their own implementations.

I would help out after I either finish my college or get booted out from there for failing to finish it (I currently need a consultant for my master's thesis I'm making on my project written in D, contact me if you would want to help me out in this, I'll provide you with two way Hungarian-English translation), I'm already planning my suggestions and contribution for a better vector support (I would suggest to add 32 bit and 64 bit fixed-point vectors, the 32 bit ones would be great for per-pixel graphics in certain cases to avoid workarounds).
April 14
On 14/04/2017 2:22 PM, solidstate1991 wrote:
> Since the backend is no longer restrained by Symantec licenses, there's
> no reason why there should be only be x86 and amd64 CPU support even if
> GDC and LDC already have their own implementations.

Here is my suggestion, try and document the backend.
You may form a very different opinion after trying to do that or come up with a game plan on how to implement non-X86 targets.

May 17
On Friday, 14 April 2017 at 13:29:35 UTC, rikki cattermole wrote:
>
> Here is my suggestion, try and document the backend.
> You may form a very different opinion after trying to do that or come up with a game plan on how to implement non-X86 targets.

As I see there's a lot of problem with the DLL support under Windows, I'm accepting your suggestion and help the x86 side first instead. I still don't have a hardware to test the compiler in the future (will getting a RPi Zero and RPi 3 in the future as well as other popular single board PCs to debug my own projects on different targets).
May 17
On Wednesday, 17 May 2017 at 18:05:32 UTC, solidstate1991 wrote:
> I still don't have a hardware to test the compiler in the future (will getting a RPi Zero and RPi 3 in the future as well as other popular single board PCs to debug my own projects on different targets).

Can't you run it in qemu?
6 days ago
On Wednesday, 17 May 2017 at 22:16:35 UTC, Kagamin wrote:
>
> Can't you run it in qemu?

Probably I could, might even work parallel with other stuff, especially stuff that are mainly lexical (register naming, etc). So far I studied the ARM assembly language, and it seems less scary than the x86 one, also the conditional execution might be useful with the ? : operators (if thumb isn't used).
5 days ago
On Monday, 22 May 2017 at 01:05:04 UTC, solidstate1991 wrote:
> On Wednesday, 17 May 2017 at 22:16:35 UTC, Kagamin wrote:
>>
>> Can't you run it in qemu?
>
> Probably I could, might even work parallel with other stuff, especially stuff that are mainly lexical (register naming, etc). So far I studied the ARM assembly language, and it seems less scary than the x86 one, also the conditional execution might be useful with the ? : operators (if thumb isn't used).

Conditional execution is not in the later models of ARM, I believe.
Also does not really provide advantages over conditional jumps, except in rare circumstances.
2 days ago
On Monday, 22 May 2017 at 14:49:46 UTC, Stefan Koch wrote:
>
> Conditional execution is not in the later models of ARM, I believe.
> Also does not really provide advantages over conditional jumps, except in rare circumstances.

That might be the case, maybe that's how they made space to address the 32 registers by cutting the rarely used conditional execution function.
2 days ago
On Thursday, 25 May 2017 at 20:47:42 UTC, solidstate1991 wrote:
> On Monday, 22 May 2017 at 14:49:46 UTC, Stefan Koch wrote:
>>
>> Conditional execution is not in the later models of ARM, I believe.
>> Also does not really provide advantages over conditional jumps, except in rare circumstances.
>
> That might be the case, maybe that's how they made space to address the 32 registers by cutting the rarely used conditional execution function.

No, they removed it from AArch64 because it complicates things on modern Out Of Order Execution high performance CPU. It was a brillant idea on the original ARM design that had no caches and a very small transistor budget, but doesn't bring much, or even is hindering, in the times of pipelining, OOOE and branch predictions.
The transition from 32 to 64 bits brought the opportunity to clean up the ISA. Because one thing that people often do not know, is that ARM ISA has probably even more legacy baggage than x86 (ARM encoding, thumbs, thumbs2, vfp, arm4, arm5, arm6, arm7, etc.).
It is often a problem and it happens in a lot of ISA's that things that were good ideas for a certain process size become real problems later on that slow down or block evolution. Examples abound, double indirect addressing modes in m68k, branch delay slots in MIPS and SPARC, register windows in SPARC, memory based register in TMS9900, predicates, shifts and PC in normal register in ARM, variable length encoding and segments in x86 etc...
2 days ago
On Thursday, 25 May 2017 at 21:15:57 UTC, Patrick Schluter wrote:
> On Thursday, 25 May 2017 at 20:47:42 UTC, solidstate1991 wrote:
>> On Monday, 22 May 2017 at 14:49:46 UTC, Stefan Koch wrote:
>>>
>>> Conditional execution is not in the later models of ARM, I believe.
>>> Also does not really provide advantages over conditional jumps, except in rare circumstances.
>>
>> That might be the case, maybe that's how they made space to address the 32 registers by cutting the rarely used conditional execution function.

Of course you're right, that's how they reused the 4 bits freed by the predicates. I should not answer posts when I'm half asleep.

>
> No, they removed it from AArch64 because it complicates things on modern Out Of Order Execution high performance CPU. It was a brillant idea on the original ARM design that had no caches and a very small transistor budget, but doesn't bring much, or even is hindering, in the times of pipelining, OOOE and branch predictions.
> The transition from 32 to 64 bits brought the opportunity to clean up the ISA. Because one thing that people often do not know, is that ARM ISA has probably even more legacy baggage than x86 (ARM encoding, thumbs, thumbs2, vfp, arm4, arm5, arm6, arm7, etc.).
> It is often a problem and it happens in a lot of ISA's that things that were good ideas for a certain process size become real problems later on that slow down or block evolution. Examples abound, double indirect addressing modes in m68k, branch delay slots in MIPS and SPARC, register windows in SPARC, memory based register in TMS9900, predicates, shifts and PC in normal register in ARM, variable length encoding and segments in x86 etc...