Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion The situation with LDC and ARM

Received: by 10.50.222.168 with SMTP id qn8mr4916366igc.3.1341641790173;
        Fri, 06 Jul 2012 23:16:30 -0700 (PDT)
X-BeenThere: ldc-dev@googlegroups.com
Received: by 10.231.74.81 with SMTP id t17ls10615884ibj.0.gmail; Fri, 06 Jul
 2012 23:16:28 -0700 (PDT)
Received: by 10.50.179.66 with SMTP id de2mr4913418igc.4.1341641788804;
        Fri, 06 Jul 2012 23:16:28 -0700 (PDT)
Received: by 10.50.179.66 with SMTP id de2mr4913416igc.4.1341641788780;
        Fri, 06 Jul 2012 23:16:28 -0700 (PDT)
Return-Path: <xtzgzo...@gmail.com>
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182])
        by gmr-mx.google.com with ESMTPS id ad4si1403897igc.1.2012.07.06.23.16.28
        (version=TLSv1/SSLv3 cipher=OTHER);
        Fri, 06 Jul 2012 23:16:28 -0700 (PDT)
Received-SPF: pass (google.com: domain of xtzgzo...@gmail.com designates 209.85.214.182 as permitted sender) client-ip=209.85.214.182;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of xtzgzo...@gmail.com designates 209.85.214.182 as permitted sender) smtp.mail=xtzgzo...@gmail.com; dkim=pass header...@gmail.com
Received: by obbun3 with SMTP id un3so11516041obb.41
        for <ldc-dev@googlegroups.com>; Fri, 06 Jul 2012 23:16:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=ql17ynXOiY1uuptP9xKBqfDSHsIk2GGzRcTZrBOzfq0=;
        b=nsybG6Vbl9sMNaI8VMdlwUr6DAJbtKMVIVq9/MeUApBjRA6/5naz3rtVfFZL0VKF8j
         wLYdgVZhZXjdh80+WScpg+zJYd/jugV0l4OCninRBvd3vezjidq/6EJJxPUlwjqzm9Ad
         6mHdooelt8PJ9mel41juhRE6tjmAQahgmCx2iUIIvjq/CrE6+Uu2aJbEc29YdeT7LHqv
         FN3hQ5T2u3vIsOSbY9r8AO3n1fBXIJIt/fh9FpleK83Wo+DNHIzJufPw/X+F3r61xR9x
         WhyyDcUY8NArSa7hi/avdx0tXrf8QowbaRXCYfzDQd2oRoNfHENQG9hTt9z9gYeo1G7I
         bfSQ==
MIME-Version: 1.0
Received: by 10.60.154.232 with SMTP id vr8mr33738914oeb.30.1341641788371;
 Fri, 06 Jul 2012 23:16:28 -0700 (PDT)
Received: by 10.182.133.73 with HTTP; Fri, 6 Jul 2012 23:16:28 -0700 (PDT)
In-Reply-To: <1E38A2C5-D980-40D5-AE97-7D99AB18D...@klickverbot.at>
References: <CAEnAdhZG_-=YS6j=VNTfhpVL35v6bohkNwT9VLQ1yG9pikH...@mail.gmail.com>
	<1E38A2C5-D980-40D5-AE97-7D99AB18D...@klickverbot.at>
Date: Sat, 7 Jul 2012 08:16:28 +0200
Message-ID: <CAEnAdhbPhv6jL_O3ZkLXjtn2r1Afhmim6NYNckjLzxxqwAd...@mail.gmail.com>
Subject: Re: [ldc-dev] The situation with LDC and ARM
From: =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzo...@gmail.com>
To: ldc-dev@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 7, 2012 at 8:11 AM, David Nadlinger <da...@klickverbot.at> wrot=
e:
> On 7 Jul 2012, at 7:51, Alex R=F8nne 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 directl=
y
> emits object files using the LLVM MC framework. Thus, we have to parse an=
y
> 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 we=
ll:
> https://github.com/ldc-developers/ldc/wiki/LLVM-inline-assembly-expressio=
ns

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