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).

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.

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).

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?

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).

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.

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.

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...

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...