February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | On 2/2/2015 1:39 AM, Johannes Pfau wrote: > No, it doesn't even come close. > > * Ports.B += 7 doesn't work. This should not be done with MMIO because the read and write cycles generated are ill-defined and vary based on obscure backend details. > In order to implement it you need a > Volatile!ubyte wrapper, return by ref and avoid some compiler bugs What compiler bugs? > * You do need force-inline to produce halfway decent code Nope. volatileLoad() and volatileStore() do not produce function calls. > * You also need to enable backend optimization to produce decent code Not any more true than with volatile types, because the compiler intrinsic actually translates to a volatile type, not a function call. You are making a lot of assumptions that volatileLoad() and volatileStore() do not work. Please try it, examine the generated code, and see. |
February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Monday, 2 February 2015 at 09:22:41 UTC, Walter Bright wrote:
> On 2/1/2015 11:16 PM, Iain Buclaw via Digitalmars-d wrote:
>> Where is the @property? :)
>
> yeah, yeah !!
BTW, when D's property will finally be cleaned up?...
I did miss something, or there is still a "-property" flag out there?
|
February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2 February 2015 at 10:57, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/2/2015 1:39 AM, Johannes Pfau wrote:
>>
>> No, it doesn't even come close.
>>
>> * Ports.B += 7 doesn't work.
>
>
> This should not be done with MMIO because the read and write cycles generated are ill-defined and vary based on obscure backend details.
>
>
>> In order to implement it you need a
>> Volatile!ubyte wrapper, return by ref and avoid some compiler bugs
>
>
> What compiler bugs?
>
>
>> * You do need force-inline to produce halfway decent code
>
>
> Nope. volatileLoad() and volatileStore() do not produce function calls.
>
I think he was referring to ubyte B() and void B(), and not the
load/store intrinsics themselves.
|
February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2 February 2015 at 07:47, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/1/2015 3:29 AM, weaselcat wrote:
>>
>> On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau wrote:
>>>
>>> which perform as well as C code, but only with force-inline
>>
>>
>> why is this still not part of the language? I'm not sure of anything else
>> that
>> has been repeatedly asked for without any good counterarguments.
>
>
> Because http://wiki.dlang.org/DIP56 generated nothing but controversy.
I'm pretty sure the only controversy is that you want it to be a pragma, everyone else wants it to be an attribute. I don't think anyone has argued against a force_inline.
|
February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On Monday, 2 February 2015 at 14:43:22 UTC, Manu wrote:
> I'm pretty sure the only controversy is that you want it to be a
> pragma, everyone else wants it to be an attribute. I don't think
> anyone has argued against a force_inline.
I also support pragma, but didn't agree with proposed semantics (that force_inline doesn't actually force). And Walter completely disagreed with any alternative proposals making any further progress in search of compromise effectively impossible.
|
February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2 February 2015 at 20:57, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 2/2/2015 1:39 AM, Johannes Pfau wrote: >>> * You do need force-inline to produce halfway decent code > > > Nope. volatileLoad() and volatileStore() do not produce function calls. They need to be wrapped to be useful, and in this case, the wrapping should not result in function calls either. I have the same problem with simd intrinsics. Intrinsics are useless if they are to be wrapped by a function call to use them in a practical way. |
February 02, 2015 force_inline etc. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | Can we just have this: pragma(inline) means "inline it unless you literally can't make it work". pragma(force_inline) or pragma(always_inline) means "the same as pragma(inline), but stop compilation if it can't be inlined". in the absence of either of these, "inline as you please". A pragma is OK. It will get the job done. People need something to get the job done. If Walter really doesn't like the attribute route then give his taste the benefit of the doubt and let's move on. |
February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On Monday, 2 February 2015 at 14:43:22 UTC, Manu wrote:
> On 2 February 2015 at 07:47, Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 2/1/2015 3:29 AM, weaselcat wrote:
>>>
>>> On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau wrote:
>>>>
>>>> which perform as well as C code, but only with force-inline
>>>
>>>
>>> why is this still not part of the language? I'm not sure of anything else
>>> that
>>> has been repeatedly asked for without any good counterarguments.
>>
>>
>> Because http://wiki.dlang.org/DIP56 generated nothing but controversy.
>
> I'm pretty sure the only controversy is that you want it to be a
> pragma, everyone else wants it to be an attribute. I don't think
> anyone has argued against a force_inline.
I don't care if it is a pragma or attribute or whatever, it just *needs to exist*.
|
February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 2/2/15 6:55 AM, Dicebot wrote:
> On Monday, 2 February 2015 at 14:43:22 UTC, Manu wrote:
>> I'm pretty sure the only controversy is that you want it to be a
>> pragma, everyone else wants it to be an attribute. I don't think
>> anyone has argued against a force_inline.
>
> I also support pragma, but didn't agree with proposed semantics (that
> force_inline doesn't actually force). And Walter completely disagreed
> with any alternative proposals making any further progress in search of
> compromise effectively impossible.
I think it's time to reopen that negotiation. -- Andrei
|
February 02, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Am Mon, 02 Feb 2015 02:57:28 -0800 schrieb Walter Bright <newshound2@digitalmars.com>: > On 2/2/2015 1:39 AM, Johannes Pfau wrote: > > No, it doesn't even come close. > > > > * Ports.B += 7 doesn't work. > > This should not be done with MMIO because the read and write cycles generated are ill-defined and vary based on obscure backend details. > Operator overloading? If +=7 is implemented as a volatileLoad + modify volatileStore as wrapper would your whole point is void. > > > In order to implement it you need a > > Volatile!ubyte wrapper, return by ref and avoid some compiler > > bugs > > What compiler bugs? > > > > * You do need force-inline to produce halfway decent code > > Nope. volatileLoad() and volatileStore() do not produce function > calls. > This was a reply to your example. Your example used a function which wrapped volatileLoad: >>> static ubyte B() { return volatileLoad(cast(ubyte *)0x0025); } I think it's obvious were a force-inline would go. > > > * You also need to enable backend optimization to produce decent code > > Not any more true than with volatile types, because the compiler intrinsic actually translates to a volatile type, not a function call. > I've explained that in detail: https://forum.dlang.org/post/manfpc$2v0u$1@digitalmars.com I'm not going to explain it again. Also your focus on intrinsics is wrong, I'm not talking about the intrinsics I'm talking about wrappers. > > You are making a lot of assumptions that volatileLoad() and > volatileStore() do not work. Please try it, examine the generated > code, and see. > Nice ad hominem. I've implemented volatileLoad/store for GDC long before you implemented it in DMD. I've written a Volatile!T wrapper, a Register wrapper and a tool which scrapes datasheets for Register definitions and automatically generates Register definitions. I've also fixed GDC for 8bit AVR processors and run and tested D code with volatileLoad/Store on these processors. Three months ago. I'm not making any assumptions about how volatileLoad/Store work, I know it quite well. Again the problem is not volatileLoad/Store which translate to single instructions it's wrappers. All the points I made come from experience implementing and using these wrappers. I don't see any point continuing this discussion as long as you don't take me seriously. At least you could read my replies properly. |
Copyright © 1999-2021 by the D Language Foundation