On Tuesday, 20 June 2017 at 16:59:03 UTC, Johan Engelen wrote:
> Not the answer you are looking for ("PRs welcome" ;-), but:
> does `make ldc2` do the trick?

That's perfectly fine, and it works. (I tried it only with `ninja ldc2`)

On 20 Jun 2017, at 17:31, Luís Marques via digitalmars-d-ldc wrote:
> BTW, is there a flag to avoid trying to build Phobos and druntime, since those fail with an unsupported target?

You can actually disable building Phobos by setting PHOBOS2_DIR to an empty string, but I believe the "all" target always includes druntime right now.

As pointed out elsewhere in this thread, just building the "ldc2" target should work, though.

 — David

Hi Luís,

On 20 Jun 2017, at 16:29, Luís Marques via digitalmars-d-ldc wrote:
> BTW, what part of the D spec that isn't x86 specific clashes with 16 bit? Over the years I've seen people saying that D can't be used for <32 bits, but I don't remember seeing anything in the spec that was actually a problem. Now, if we were talking about weird type sizes (9-bit chars...) that would be different.
>
> FYI: My first quick test compiled fine (to assembly; I don't think the target supports object file generation; I have to finish assembly and linking with the gnu tools, like I did for RISC-V).

It is more of a general statement of direction rather than any one thing that clashes with narrower architectures in particular (which, I agree, is confusing, but perhaps Walter didn't want to give the impression that DMD was on par with DMC when it comes to 16 bit DOS executables).

Two things that are not supported are non-power-of-two address widths and non-flat pointer types (segmented memory, or different near/far pointer types). Some of the library artefacts like the GC also won't work well with such a small memory space.

Best,
David

On Tuesday, 20 June 2017 at 15:29:35 UTC, Luís Marques wrote:
> FYI: My first quick test compiled fine (to assembly; I don't think the target supports object file generation; I have to finish assembly and linking with the gnu tools, like I did for RISC-V).

It seems that `clang --target=msp430 -c test.c` generates an object file successfully, while `ldc2 -O2 -mtriple=msp430 -c test.d` fails:

```
no support for asm output
UNREACHABLE executed at ../driver/toobj.cpp:130!
0  ldc2                     0x0000000107e19c9c llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
1  ldc2                     0x0000000107e1a1e9 PrintStackTraceSignalHandler(void*) + 25
2  ldc2                     0x0000000107e16139 llvm::sys::RunSignalHandlers() + 425
3  ldc2                     0x0000000107e1a642 SignalHandler(int) + 354
4  libsystem_platform.dylib 0x00007fffa0ad5b3a _sigtramp + 26
5  libsystem_platform.dylib 0x0000000000000003 _sigtramp + 1599251683
6  libsystem_c.dylib        0x00007fffa095a420 abort + 129
7  ldc2                     0x0000000107d246c0 LLVMInstallFatalErrorHandler + 0
8  ldc2                     0x0000000105efd2a7 codegenModule(llvm::TargetMachine&, llvm::Module&, llvm::raw_fd_ostream&, llvm::TargetMachine::CodeGenFileType) + 391
9  ldc2                     0x0000000105f00ab9 (anonymous namespace)::writeObjectFile(llvm::Module*, char const*) + 377
10 ldc2                     0x0000000105efcc05 writeModule(llvm::Module*, char const*) + 10517
11 ldc2                     0x0000000105ee6162 ldc::CodeGenerator::writeAndFreeLLModule(char const*) + 1602
12 ldc2                     0x0000000105ee6a82 ldc::CodeGenerator::finishLLModule(Module*) + 130
13 ldc2                     0x0000000105ee880c ldc::CodeGenerator::emit(Module*) + 1420
14 ldc2                     0x0000000105f36e4e codegenModules(Array<Module*>&) + 574
15 ldc2                     0x0000000105bf2a00 mars_mainBody(Array<char const*>&, Array<char const*>&) + 5120
Abort trap: 6
```

Curiously, if you do `clang --target=msp430 -S -emit-llvm test.c` and then you try to generate the object file from test.ll, llc fails:

```
llc -filetype=obj test.ll
/opt/msp430/bin/llc: target does not support generation of this file type!
```

Any idea on how we can get LDC to generate object files directly?

On Wednesday, 5 July 2017 at 18:16:39 UTC, Luís Marques wrote:
> 
> It seems that `clang --target=msp430 -c test.c` generates an object file successfully, while `ldc2 -O2 -mtriple=msp430 -c test.d` fails:

Perhaps it's good to verify that the clang and LDC triples are the same.
Just the first thing that came to mind,
 Johan

On Wednesday, 5 July 2017 at 21:16:11 UTC, Johan Engelen wrote:
> Perhaps it's good to verify that the clang and LDC triples are the same.

They are:

source_filename = "test.d"
target datalayout = "e-m:e-p:16:16-i32:16:32-a:16-n8:16"
target triple = "msp430"

source_filename = "test.c"
target datalayout = "e-m:e-p:16:16-i32:16:32-a:16-n8:16"
target triple = "msp430"

On Wednesday, 5 July 2017 at 22:13:36 UTC, Luís Marques wrote:
> On Wednesday, 5 July 2017 at 21:16:11 UTC, Johan Engelen wrote:
>> Perhaps it's good to verify that the clang and LDC triples are the same.
>
> They are:
>
> source_filename = "test.d"
> target datalayout = "e-m:e-p:16:16-i32:16:32-a:16-n8:16"
> target triple = "msp430"

Hm, doesn't really look like a "triple" (3), but OK :-)
Can you ask on the LLVM list about the `llc` failure? You may get a hint about how to make LDC behave the same as Clang on this point.

Perhaps asking too much but, you could also try searching through Clang's codebase to see if there is any relevant special casing for the msp430 target.

-Johan

On Wednesday, 5 July 2017 at 23:33:37 UTC, Johan Engelen wrote:
> Hm, doesn't really look like a "triple" (3), but OK :-)

It's probably equivalent to msp430-elf-unknown or something like that. Hey, these days the "triples" can have 4 parts so...

> Can you ask on the LLVM list about the `llc` failure? You may get a hint about how to make LDC behave the same as Clang on this point.
>
> Perhaps asking too much but, you could also try searching through Clang's codebase to see if there is any relevant special casing for the msp430 target.

OK.

On Wednesday, 5 July 2017 at 23:39:09 UTC, Luís Marques wrote:
>> Can you ask on the LLVM list about the `llc` failure? You may get a hint about how to make LDC behave the same as Clang on this point.

Reply:

"There is no direct object emission support in MSP430 backend. clang
executed assembler under the hood."

Should LDC also learn to do this?

On Thursday, 6 July 2017 at 00:27:23 UTC, Luís Marques wrote:
> Should LDC also learn to do this?

Nicholas Wilson suggested -no-integrated-as in the LLVM mailing list, although it seems it doesn't quite work. But at least the flag is already there, and can be made default for MSP430 (maybe for all archs that don't have code generation?).