The situation with LDC and ARM

[Alex Rønne Petersen]

Hey list,

So, I've been poking at LDC on ARM. Building and using the compiler
basically works as expected when *not* using druntime and phobos. In
this sense, the ARM port is complete. However, druntime and phobos are
far from ported to ARM; a lot of code (such as varargs stuff, register
saving/restoring, fibers, ...) is incomplete. This makes it impossible
to use the threading and GC infrastructure in druntime (or even
compiling it in the first place).

Now, normally finishing a port is simple: Just fill in the
arch-specific stuff. Unfortunately, a lot of the things that need to
be ported (such as register saving) use inline assembly on x86 and
have no LLVM intrinsics to do the equivalent operation portably.
Further, LDC (to my knowledge; please prove me wrong) has no
generalized inline assembly that's simply passed to the underlying
assembler, like GDC's inline assembly. This means that I would have to
resort to writing this code in an external assembly file and linking
the resulting object into druntime. Not pretty at all; adds complexity
to the build process and makes porting more of a general pain in the
ass.

The inline assembly GDC has:
http://gdcproject.org/wiki/UserDocumentation#line-79

Unless anyone can think of some other solution, I really think LDC
should implement this too. Not only would it enable us to share code
between the two compilers, it would also simplify porting.

Regards,
Alex

[David Nadlinger]

On 7 Jul 2012, at 7:51, Alex Rønne Petersen wrote:
> Further, LDC (to my knowledge; please prove me wrong) has no
> generalized inline assembly that's simply passed to the underlying
> assembler, like GDC's inline assembly.

Just for the records: LDC does not use a standalone assembler, it
directly emits object files using the LLVM MC framework. Thus, we have
to parse any inline assembly prior to that (but there are LLVM libraries
to do so for most targets).

> The inline assembly GDC has:
> http://gdcproject.org/wiki/UserDocumentation#line-79

We have something similar, but OTOH I don't know if it works on ARM as
well:
https://github.com/ldc-developers/ldc/wiki/LLVM-inline-assembly-expressions

David

[Alex Rønne Petersen]

On Sat, Jul 7, 2012 at 8:11 AM, David Nadlinger <da...@klickverbot.at> wrote:
> On 7 Jul 2012, at 7:51, Alex Rønne Petersen wrote:
>>
>> Further, LDC (to my knowledge; please prove me wrong) has no
>> generalized inline assembly that's simply passed to the underlying
>> assembler, like GDC's inline assembly.
>
>
> Just for the records: LDC does not use a standalone assembler, it directly
> emits object files using the LLVM MC framework. Thus, we have to parse any
> inline assembly prior to that (but there are LLVM libraries to do so for
> most targets).

I assume this is what LLVM does anyway when you create InlineAsm
objects in Modules. But I don't actually know; that's just what I
would expect from the assembly docs.

>
>
>> The inline assembly GDC has:
>> http://gdcproject.org/wiki/UserDocumentation#line-79
>
>
> We have something similar, but OTOH I don't know if it works on ARM as well:
> https://github.com/ldc-developers/ldc/wiki/LLVM-inline-assembly-expressions

That's interesting. I'll definitely give that a try; seems like (if it
works on all targets) it could do the same thing GDC's inline assembly
does.

Still, I think unification of inline assembly would be favorable.
Couldn't the mechanics behind those magic __asm intrinsics just be
hooked up to GDC's inline assembly syntax?

Regards,
Alex

[David Nadlinger]

On 7 Jul 2012, at 8:16, Alex Rønne Petersen wrote:
> On Sat, Jul 7, 2012 at 8:11 AM, David Nadlinger <da...@klickverbot.at>
> wrote:
>> Just for the records: LDC does not use a standalone assembler, it
>> directly
>> emits object files using the LLVM MC framework. Thus, we have to
>> parse any
>> inline assembly prior to that (but there are LLVM libraries to do so
>> for
>> most targets).
>
> I assume this is what LLVM does anyway when you create InlineAsm
> objects in Modules. But I don't actually know; that's just what I
> would expect from the assembly docs.

Yes, but there needs to be a MC AsmParser for the given architecture
because we are using MC to emit code. There is one for x86 and ARM, but
e.g. not for PPC. There is no way to just "splice" inline assembly into
the output like when using a standalone assembler.

David

[Alex Rønne Petersen]

That makes me curious then; how does the __asm magic work for PPC
currently? (The wiki page you linked shows a PPC example.)

Regards,
Alex

[Alex Rønne Petersen]

I just looked into this in the LDC source and it appears that the
magic __asm stuff is just translated into llvm::InlineAsm objects as I
suspected. This should work for any target that has an assembler (MC
or not) available, no? That's the impression I get from the docs:
http://llvm.org/docs/LangRef.html#moduleasm

Regards,
Alex

[David Nadlinger]

On 7 Jul 2012, at 20:29, Alex Rønne Petersen wrote:
> I just looked into this in the LDC source and it appears that the
> magic __asm stuff is just translated into llvm::InlineAsm objects as I
> suspected. This should work for any target that has an assembler (MC
> or not) available, no? That's the impression I get from the docs:
> http://llvm.org/docs/LangRef.html#moduleasm

It is correct that LDC just lowers this to LLVM IR inline assembly
expressions, but for them to work when using MC to codegen (i.e. not
resorting to an external assembler), there needs to be a MC asm parser
in place. If not, you'll get an error according to the lines of »Inline
asm not supported by this streamer because we don't have an asm parser
for this target«.

Right now, I think LDC should even fail to build for PowerPC because of
this – it should really be fixed, but apparently nobody complained so
far (see https://github.com/ldc-developers/ldc/issues/38).

David