DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 16 01:35:09 PDT 2014


On 16 July 2014 08:16, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 7/15/2014 11:23 PM, Iain Buclaw via Digitalmars-d wrote:
>>
>> GDC doesn't support it as compiler intrinsics.
>
>
> I know.
>
>
>
>> Also, isn't inp/outp all x86-specific?
>
> Yes. This is not an argument that x86 compilers shouldn't support them.
> After all, D is supposed to be a systems programming language.
>

It certainly isn't! And it is never my intention to prevent
optimisations on one platform if another doesn't benefit.

I think my argument comes down to this, consider the following
compiler intrisinsic.
---
ubyte inp(uint port_address);


It should instead be written as.
---
ubyte inp()(uint port_address)
{
    version(ARM)
    {
        asm { /* ... */ }
    }
    else
        static assert(false, "Not Implemented");
}


What's going on here?

1) If the compiler recognises the function as an intrinsic, it
discards the body and does whatever it knows to be correct.
2) If its not an intrinsic, it falls back to the library implementation.
3) So not to hurt targets that do not support inp/outp, it only errors
at compile-time if *actually* used.



As an alternative, instead of a template, we could use core.internal
to do the same thing in this way.

core/internal/bitops.d
---
module core.bitops;

version(ARM)
{
    ubyte inp(uint port_address)
    {
        /* ... */
    }
}


core/bitops.d
---
module core.bitops;

ubyte inp(uint port_address);


But then it falls down to a linker error if
1) The compiler didn't expand inp() in the backend
2) core.internal.bitops doesn't implement inp()

Which would you prefer?

Regards
Iain.


More information about the Digitalmars-d mailing list