February 23, 2005
> I had forgotten about this bug where initializers aren't inlined. Everything works fine if you replace
>      int i = flip(0xFE);
> with
>      int i;
>      i = flip(0xFE);
> or if you hadn't used a variable at all and instead just wrote
> writef("%d\n", flip(0xFE));
> 
> Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.
> 
> -Ben 
> 
> 
Not quite fine - the function gets inlined, and called with the parameter 0xFE.  This correctly gets converted to 0x7F, but it gets converted at runtime, not compiletime.

Brad
February 23, 2005
Aleksey Bobnev wrote:
>>Though I think the syntax is on the clunky side :)
> 
> 
> The better way:
> 
> template Foo(int n)
> {
>      const int Foo = n - 1;
> }
> 
> const int test = Foo!(10);
> 
> 
Ah, much nicer.  I thought there should be a way to do that, but didn't know the template syntax well enough.

Brad
February 23, 2005
"brad beveridge" <brad@nowhere.com> wrote in message news:cvij05$1mdo$1@digitaldaemon.com...
>
>> I had forgotten about this bug where initializers aren't inlined.
>> Everything works fine if you replace
>>      int i = flip(0xFE);
>> with
>>      int i;
>>      i = flip(0xFE);
>> or if you hadn't used a variable at all and instead just wrote
>> writef("%d\n", flip(0xFE));
>>
>> Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.
>>
>> -Ben
> Not quite fine - the function gets inlined, and called with the parameter 0xFE.  This correctly gets converted to 0x7F, but it gets converted at runtime, not compiletime.
>
> Brad

Did you pass the -inline and -O flags to the compiler? When I tell the compiler to inline and optimize it does everything at compile time (except with the initiliazer bug). Without those flags it doesn't.


February 23, 2005
Ben Hinkle wrote:
> "brad beveridge" <brad@nowhere.com> wrote in message news:cvij05$1mdo$1@digitaldaemon.com...
> 
>>>I had forgotten about this bug where initializers aren't inlined. Everything works fine if you replace
>>>     int i = flip(0xFE);
>>>with
>>>     int i;
>>>     i = flip(0xFE);
>>>or if you hadn't used a variable at all and instead just wrote
>>>writef("%d\n", flip(0xFE));
>>>
>>>Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.
>>>
>>>-Ben
>>
>>Not quite fine - the function gets inlined, and called with the parameter 0xFE.  This correctly gets converted to 0x7F, but it gets converted at runtime, not compiletime.
>>
>>Brad
> 
> 
> Did you pass the -inline and -O flags to the compiler? When I tell the compiler to inline and optimize it does everything at compile time (except with the initiliazer bug). Without those flags it doesn't. 
> 
> 
My apologies - you are correct.  I wasn't using the -O flag.  Though the initialiser not inlining/optimising thing is annoying.

Brad
February 23, 2005
In article <cvi17n$ubp$1@digitaldaemon.com>, Ben Hinkle says...
>I had forgotten about this bug where initializers aren't inlined. Everything works fine if you replace
>     int i = flip(0xFE);
>with
>     int i;
>     i = flip(0xFE);
>or if you hadn't used a variable at all and instead just wrote
>writef("%d\n", flip(0xFE));
>
>Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.


I'll second that ~ such thing can cause much wailing, and gnashing of teeth.

- Kris


February 25, 2005
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:cvi17n$ubp$1@digitaldaemon.com...
>
> "brad beveridge" <brad@nowhere.com> wrote in message news:cvhc9r$1vm$1@digitaldaemon.com...
> > brad beveridge wrote:
> >>
> >>> That's ok - trusting the compiler can be risky. Though if dmd's
inlining
> >>> and constant folding can't produce the same result in your case as a C
> >>> compiler would then Walter needs to spend some time and fix that.
> >>> See also http://www.digitalmars.com/d/htomodule.html the section about
> >>> macros and http://www.digitalmars.com/d/pretod.html the section about
> >>> macros.
> >>> Inlining is your friend!
> >>
> >>
> >> That's good to hear, and it is what I expected.  I had thought that
what
> >> might happen is
> >> 1) Constant folding occurs (ie, 0xF0 - this is as reduced as it can
get)
> >> 2) Inlining occurs, the ~ operation still has to happen on 0xF0.
> >> But if constant folding occurs after inlining, then everything is OK.
If
> >> I am feeling particularly bored I might need to look at the assembler output.
> >>
> >> I think the template method is closer to what I am wanting.
> >>
> >> Brad
> > As much as replying to my own post is poor form, here I am doing it. The
> > following code illustrates both methods
> > 1) Inlining a function call of a constant
> > 2) Generating a constant with a template
> > The bad news is that you were wrong Ben :)
> > (1) doesn't give optimal results
> > (2) does
> > D doesn't inline & then fold constants.  Which makes sense - I don't
know
> > much about compilers/optimisers, but I expect that an optimiser would
need
> > to be very smart to decide "hey, this function has constant inputs,
maybe
> > I should evaluate it at compile time and see if I can give it a constant output"
> >
> > Anyhow, here is some sample code.  A little grovelling through the assembler output shows what is going on.
> >
> > Brad
> >
> > import std.stdio;
> >
> > int flip(int x)
> > {
> >     return ( ((x & 0x80) >> 7) |
> >                           ((x & 0x40) >> 5) |
> >                           ((x & 0x20) >> 3) |
> >                           ((x & 0x10) >> 1) |
> >                           ((x & 0x08) << 1) |
> >                           ((x & 0x04) << 3) |
> >                           ((x & 0x02) << 5) |
> >                           ((x & 0x01) << 7) );
> > }
> >
> > template tflip(int x)
> > {
> >     const int val = ( ((x & 0x80) >> 7) |
> >                           ((x & 0x40) >> 5) |
> >                           ((x & 0x20) >> 3) |
> >                           ((x & 0x10) >> 1) |
> >                           ((x & 0x08) << 1) |
> >                           ((x & 0x04) << 3) |
> >                           ((x & 0x02) << 5) |
> >                           ((x & 0x01) << 7) );
> >
> > }
> >
> > void main()
> > {
> >     // comment these lines in/out to show that constant folding happens
> >     // before inlining.
> >
> >     // sub-optimal behaviour, the flip function is called and 0xFE
> >     // is bit flipped at runtime
> >     // note, you cannot have this int "const"
> >     //int i = flip(0xFE);
> >
> >     // optimal method - the template is evaluated at compile time
> >     // and i evaluates to 0x7F, as is correct
> >     //const int i = tflip!(0xFE).val;
> >     writef("%d\n", i);
> > }
>
> I had forgotten about this bug where initializers aren't inlined.
Everything
> works fine if you replace
>      int i = flip(0xFE);
> with
>      int i;
>      i = flip(0xFE);
> or if you hadn't used a variable at all and instead just wrote
> writef("%d\n", flip(0xFE));
>
> Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.

Yes.


February 25, 2005
brad@domain.invalid wrote:
> I'm just looking at a couple of projects, and wondering how I can convert them to D.  The point of these macros to to translate a human readable value to something that is hardware specific.  The details aren't too specific, but the macros convert from one constant form to another [...]

> I really feel like this would be a powerful addition to D (if it doesn't already support it).  If it does support it - how can I do it?

Sure does.  Try this:

    version = INVERT_COMMANDS;

    version (INVERT_COMMANDS) {
        template INVERT(int I) {
            const int INVERT = ~I;
        }

    } else {
        template INVERT(int I) {
            const int INVERT = I;
        }
    }

    version = FLIP_COMMANDS;

    version (FLIP_COMMANDS) {
        template FLIP(int X) {
            const int FLIP =
                ((x & 0x80) >> 7) |
                ((x & 0x40) >> 5) |
                ((x & 0x20) >> 3) |
                ((x & 0x10) >> 1) |
                ((x & 0x08) << 1) |
                ((x & 0x04) << 3) |
                ((x & 0x02) << 5) |
                ((x & 0x01) << 7) )
            ;
        }

    } else {
        template FLIP(int X) {
            const int FLIP = X;
        }
    }

    const int SOME_COMMAND = INVERT!(FLIP!(0xE0) & 0xFF);

 -- andy
February 26, 2005
Derek Parnell <derek@psych.ward> wrote:

[...]
> I've occasionally thought that a write-once type of variable would be a useful addition to a language.

sather has `once' parameters

<cite href="http://www.icsi.berkeley.edu/
~sather/Documentation/LanguageDescription/webmaker/DescriptionX2Eiter
ators-chapte-1.html#HEADING1-36">
Arguments which are marked with the mode 'once' are only evaluated
the first time they are encountered during a loop execution.
</cite>

And "once" variables are easily done in D with properties:

<example>
private:
  int m= void;
  bit assigned= false;
public:
  int i(){
    if( assigned)
      return m;
    else
      throw new Exception;
  }
  int i( int value){
    if( assigned)
      throw new Exception;
    else {
      m= value;
      assigned= true;
    }
  }
</example>



Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home