H1 2015 Priorities and Bare-Metal Programming

[Walter Bright via Digitalmars-d]

On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Feb 02, 2015 at 08:55:59AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 2/2/15 8:42 AM, Johannes Pfau wrote:
>>> Again the problem is not volatileLoad/Store which
>>> translate to single instructions it's wrappers.
>>
>> So does the argument boil down to better inlining control and
>> enforcement?  -- Andrei
>
> FWIW, from the POV of a bystander, the point is that force-inline for
> certain things (namely wrappers around certain intrinsics, like operator
> overloads for atomics, what-have-you) is necessary in order to guarantee
> that function call overhead will not be incurred no matter what.
>
> Walter seems to dislike forced inlining for various reasons, preferring
> inlining as a hint at the most, and he probably has a point in most
> cases (let the compiler make the judgment). But in other cases, such as
> the one in question, the user needs to override the compiler's decision.
> Currently there's no way to do that, and it's a showstopper for those
> users.

This is a settled issue. After all, I wrote:

http://wiki.dlang.org/DIP56


> Unless we're proposing to flood the compiler with intrinsics, one for
> every possible operator overload of volatile loads/stores, which I think
> should be obviously infeasible. And even then, you still might miss one
> or two other obscure wrappers that users might discover that they need.
> It seems reasonable that instead of burdening the compiler (and compiler
> maintainers, and porters) to keep up with an ever-expanding set of
> intrinsics, making use of the language to express what is needed via
> forced-inline functions is a better way to do things.

I agree that adding more language features instead of inline control is wrong.