On Sunday, 22 December 2013 at 08:11:05 UTC, Russel Winder wrote:
> Historically, and anecdotally, I found that as soon as the assembly
> language was a function, it was better as a separate entity,

Well, you can usually get what you want by first writing the code in C, then generate asm and optimize that by hand. So, being able to generate useful asm listings is more important than inlining, I think. In that respect I agree. I would much rather have the ability to generate tight and readable/auto-commented ASM than having inlining.

> that inline
> assembler only worked for accessing a processor instruction that the
> code generator could not generate. So I think you are making this same
> point, cf. SIMD instructions at the bleeding edge.

Well, yes, but if you are doing projects where you know the hardware and the hardware is specialized and limited (e.g. tiny amounts of RAM/ROM, no division/multiply, System on a Chip etc) it becomes a little bit more attractive to be able to do asm here and there: get the most out of flag-registers (like carry, overflow etc), run without an OS and write tight IRQ handlers. Like art-installations, small robots, embedded things? Granted, this is not something D is suitable for atm, but I hope it will move in that direction, eventually. I think it could become a hit.

Regarding bleeding edge: AFAIK, inlined asm is necessary if you want to benefit effectively from transactional memory in Haswell processors today, although it would be much much more convenient with language support. It is hard to get right, because there are cache-line restrictions (objects have a minimum/maximum size, so you have to group attributes that are to be protected into the same region). I think inline asm might be useful in a heavily optimized single-purpose server for that reason. But to conveniently benefit from that the compiler have to generate ASM that the CPU-vendor's assembler can parse and without restrictions on instructions unknown to the compiler (so you don't have to resort to injecting opcodes rather than mnemonics). If inline asm implies a built in assembler then I am not at all sure if it is all that useful.

On 12/22/2013 12:05 AM, Russel Winder wrote:
>> There is no case where D's support for intel inline assembler is worse than
>> forcing you to use a separate assembler.
>
> My point is really that D needs to support ARM pdq to have any chance of
> getting traction in an increasingly bi-partisan (Intel/AMD and ARM)
> rather than monopolistic (Intel/AMD) data centre.


That is a good point and I definitely agree.

But I don't think this has much to do with inline assembler support - and supporting an assembler for ARM is simply not that hard. There's nothing tricky about an assembler or its syntax. There may be issues with supporting an inline assembler and the GDC or LDC back end interfaces, that I don't know about.

On 12/22/2013 12:10 AM, Russel Winder wrote:
> Historically, and anecdotally, I found that as soon as the assembly
> language was a function, it was better as a separate entity, that inline
> assembler only worked for accessing a processor instruction that the
> code generator could not generate. So I think you are making this same
> point, cf. SIMD instructions at the bleeding edge.

What blows about most assemblers I've had the misfortune to work with is that they did not understand C structs.

This means when you write assembler code that interfaces with your C project, you have to duplicate the C .h files in the assembler's peculiar syntax. Make a mistake, and you've got instant memory corruption. Someone changes a C .h header, instant corruption again.

It's a maintenance nightmare, and wholly unnecessary. Apparently nobody writing an assembler ever had the obvious idea of tacking on a C front end so it could at least pull the struct declarations out of the .h files.

Walter Bright:

> Apparently nobody writing an assembler ever had the obvious idea of tacking on a C front end so it could at least pull the struct declarations out of the .h files.

In D you can do the opposite: write the asm files, import them statically from D and parse and convert them with compile-time code into D struct defintions :-)


> There may be issues with supporting an inline assembler and the GDC or LDC back end interfaces, that I don't know about.

I think GDC and LDC developers are willing to give you answers on this, if you ask.

Bye,
bearophile

On Sunday, 22 December 2013 at 17:21:59 UTC, Walter Bright wrote:
> There's nothing tricky about an assembler or its syntax. There may be issues with supporting an inline assembler and the GDC or LDC back end interfaces, that I don't know about.

Both GCC and LLVM actually support more extensive inline assembly than DMD does (allowing to explicitly specify side effects so the respective piece of code can still be optimized/inlined).

David

On 20/12/13 02:40, Francesco Cattoglio wrote:
> I don't know, I feel like I would be more useful if I only sticked with working
> on the standard library when needed and writing software that others might find
> interesting (I'm planning on "resurrecting" SciD btw)

Nice to know -- anything in particular you are keen to work on there?

On 21/12/13 15:44, Russel Winder wrote:
> Inline assembly means you have to have the assembly code for each
> supported platform in the code with all the conditionals to the
> compiler. Having separate files is often much easier to manage and to
> build from.
>
> OK so D only support Intel processors just now so only one inline
> assembly type, but this is part of the problem not the solution.

That surely depends on your use-case.  There must be situations in embedded programming where it's useful to be able to just put in a handful of lines of assembly, and where there's no portability issue to cause you to get lost in a maze of conditionals.

On 21 December 2013 06:26, Paulo Pinto <pjmlp@progtools.org> wrote:
> On 20.12.2013 22:05, Jacob Carlborg wrote:
>>
>> On 2013-12-20 08:03, Paulo Pinto wrote:
>>
>>> Even though I rather use D than Go, every time I read that, I am tempted to prove people wrong. If I had the time for it, that is.
>>>
>>> Go offers the same mechanisms for systems programming as Oberon does. If ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why cannot one do an OS with Go?
>>
>>
>> When developing an OS, for somethings these languages are not enough, including C, Go and D. You need to use assembly. D has the advantage of supporting inline assembly.
>>

While useful the ability to write inline assembler functions, DMD can't inline these around the place. So you get all the benefits of being able to shortcut the fastest route to do X, but with the slowdown of 25% because there's a big elephant in the room.


>
> Until all D compilers provide the same support for inline assembly, it is better we don't use that as language feature.
>

That same support is never going to happen.  Not because of disagreement, but because our backends are designed to work most naturally in conflicting ways.  The same can be said for other (very) low-level details, such as va_list type and va_arg functions, low-level x86 intrinsics (inp, outp, y2lx...), and that core.simd.__simd thingy.

x86-specific and x86-centric are implied on all DMD's features mentioned above.

Iain.

Iain Buclaw:

> That same support is never going to happen.  Not because of
> disagreement, but because our backends are designed to work most
> naturally in conflicting ways.

I think this means that working to make DMD better is a good idea, because every compiler has different strengths, like Walter says.


> and that core.simd.__simd thingy.

What are the problems with that thing?


> x86-specific and x86-centric are implied on all DMD's features mentioned above.

While the work to support other CPUs (and GPUs) is important, even at Phobos/language level, x86 is still an important CPU, so the work to make its support good is not wasted time :-)

Bye,
bearophile

On Dec 23, 2013 12:00 AM, "bearophile" <bearophileHUGS@lycos.com> wrote:
>
> Iain Buclaw:
>
>
>> That same support is never going to happen.  Not because of disagreement, but because our backends are designed to work most naturally in conflicting ways.
>
>
> I think this means that working to make DMD better is a good idea,
because every compiler has different strengths, like Walter says.
>
>

For inline assembly, making dmd work better how?

The problem with inline assembly is much more fundamental. DMD emits object code, so it makes sense to have a full blown assembler built into it.  In contrast, GDC emits assembly, and AT&T syntax at that, so having anything other than GCC-style inline assembly support is just plain awkward.

>> and that core.simd.__simd thingy.
>
>
> What are the problems with that thing?
>

Not possible without some sort of translation map, which would be target specific, so not suitable for GDC, and language specific so not suitable for GCC either.

Also, falls under category of x86-centric below.

>
>> x86-specific and x86-centric are implied on all DMD's features mentioned
above.
>
>
> While the work to support other CPUs (and GPUs) is important, even at
Phobos/language level, x86 is still an important CPU, so the work to make its support good is not wasted time :-)
>

Indeed, but just keep that support out of the language spec, as it only serves to hurt progress, and leads to extreme conflicts in design (I don't tend to show it, but I do take extreme pity that DMD has three interfaces to va_arg - X86, X86_64, and Win64).

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';