I'm trying to assess the current state of LDC for Windows.

I'm not actually interested in using LDC to compile programs targeting Windows (at least not at the moment), but rather LDC running on Windows, compiling for ARM Cortex-M (thumb) targets.  My motivation is I'm considering using Visual D for my development, and that means using Windows.

David Nadlinger's talk at DConf 2013 stated that Windows support wasn't quite there, but I couldn't determine if he was referring to compiling for Windows, or running on Windows, or both.

Could someone please clarify?

Thanks,
Mike

Hi Mike!

LDC can be compiled with MSVC without problems. If you link again a LLVM with ARM backend, then there should be no problem using Visual-D and LDC.
But you should be aware of the broken EH handling (https://github.com/ldc-developers/ldc/issues/489) and possible problems with floats (https://github.com/ldc-developers/ldc/issues/259).

I use MSVC for most of LDC development so it is quite usable.

Another possible solution is to use mingw32. The binary from the release contains only the X86 backend but it is quite easy to link against a LLVM with ARM backend. I am unsure if the mingw32 based LDC can be used with Visual-D.

Regards,
Kai

On Monday, 2 December 2013 at 08:03:03 UTC, Mike wrote:
> I'm trying to assess the current state of LDC for Windows.
>
> I'm not actually interested in using LDC to compile programs targeting Windows (at least not at the moment), but rather LDC running on Windows, compiling for ARM Cortex-M (thumb) targets.
>  My motivation is I'm considering using Visual D for my development, and that means using Windows.
>
> David Nadlinger's talk at DConf 2013 stated that Windows support wasn't quite there, but I couldn't determine if he was referring to compiling for Windows, or running on Windows, or both.
>
> Could someone please clarify?
>
> Thanks,
> Mike

On Monday, 2 December 2013 at 08:03:03 UTC, Mike wrote:
> David Nadlinger's talk at DConf 2013 stated that Windows support wasn't quite there, but I couldn't determine if he was referring to compiling for Windows, or running on Windows, or both.

I was referring only to compiling _for_ Windows in the talk, and that situation has improved quite a bit since DConf. As far as MinGW/Win32 goes, the only thing really missing at this point is a CI slave and a bit of work to eliminate the remaining test suite failures.

As far as running LDC on Windows goes, I don't know of any remaining limitations. What bugged us for a while is the unavailability of 80 bit floating point operations in the Microsoft C runtime, but at least when building with MinGW, this should be solved by now. Maybe Kai can tell you more about the situation with MSVC builds.

With regards to cross-compiling for ARM, one thing we notably don't do yet is using the target floating point semantic for 'real', etc. during compile-time function evaluation. Whether this is a problem or not is a subject of debate – for the time being, just keep in mind that the CTFE results might be calculated with a higher precision than during runtime on the target hardware.

David

MSVC 2013 runtime has native support of 80 bit floats.

Hi Temtaine!

On Wednesday, 4 December 2013 at 09:45:10 UTC, Temtaime wrote:
> MSVC 2013 runtime has native support of 80 bit floats.

I haven't checked this but it does not solve the problem. The floating point format of the host should not really be used for cross-compiling.

Mike wnat to develop on Windows and targets ARM Cortex. The real data type is therefore the standard 64bit IEEE type. But LDC will use the x86 80bit type because it runs on Windows.

Same is true with PPC/PPC64. This architecture have a 128bit "double double" type. But running LDC on Windows, it is not possible to produce PPC/PPC64 code with the "double double".

IMHO this really needs to be fixed.

Regards,
Kai