C Bitfields in D
Okay. I'm trying to get some C code to be properly callable from some D code,
which naturally involves some extern(C) blocks. One of the types that I have to
deal with looks something like this:
typedef struct
{
unsigned i:1;
} my_struct;
I have no idea how to do such a bitfield in D. Does a std.bitmanip.bitfield
work?
I wouldn't have thought so, but I don't know. What would be the proper way to
create a properly compatible struct in D?
- Jonathan M Davis
inlining
Hello,
Does dmd inline when appropriate (eg single-line func)? or is there a hint
keyword? or what else?
Eg how to have this inlined:
private bool isPrecomposedHangulSylable (Code code) {
/** whether code is a precomposed Hangul syllable ;-) */
return (code = FIRST_HANGUL_SYLLABLE) (code = LAST_HANGUL_SYLLABLE);
}
Thank you,
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: inlining
On 12/07/10 05:05, spir wrote:
Hello,
Does dmd inline when appropriate (eg single-line func)? or is there a hint
keyword? or what else?
Eg how to have this inlined:
private bool isPrecomposedHangulSylable (Code code) {
/** whether code is a precomposed Hangul syllable ;-) */
return (code = FIRST_HANGUL_SYLLABLE) (code = LAST_HANGUL_SYLLABLE);
}
Thank you,
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
DMD performs inlining as it deems appropriate, but only if the '-inline'
switch is provided on the command line. Generally speaking, very simple
one-liners like yours will get inlined.
-- Chris N-S
Re: inlining
On Tuesday 07 December 2010 03:05:28 spir wrote:
Hello,
Does dmd inline when appropriate (eg single-line func)? or is there a hint
keyword? or what else? Eg how to have this inlined:
private bool isPrecomposedHangulSylable (Code code) {
/** whether code is a precomposed Hangul syllable ;-) */
return (code = FIRST_HANGUL_SYLLABLE) (code =
LAST_HANGUL_SYLLABLE); }
C++ has the inline keyword, and it is used only as a hint to the compiler. The
compiler is free to follow it or ignore it as it sees fit, so its usefulness is
debateable. D does _not_ have the inline keyword. It just leaves it up to the
compiler entirely. Note that the -inline flag enables inlining.
IIRC, no functions which have lazy parameters or include inline assembly will
ever be inlined. And, of course, if a function is long, the compiler is
unlikely
to choose to inline it (though maybe it would choose to if the function is only
ever called once - that's up to the inliner).
Excluding functions with lazy parameters (or which call a function with any
lazy
parameters) or which include inline assembly, any non-virtual function should
be
inlineable. So, any functions which are not members of a class could be
inlined.
Class functions which are static could be inlined. private member functions
could be inlined. And final functions which override no other function could be
inlined (assuming that the compiler does indeed make such a function
non-virtual
- it should since it can, but I don't know how smart it is about that).
Generally, inlining isn't something to worry about. The compiler will do it if
the -inline flag is used, and whatever would be appropriate to inline will be
inlined. It's likely only a concern when you're trying to eek every last ounce
of speed out of a program, and at that point, you'll have to look at the
generated assembly code to figure out whether a function is actually inlined or
not. The one place that it makes some sense to worry about it is if you're
dealing with functions that you really think should be inlined, then don't use
lazy parameters (or call functions with lazy parameters within that function)
and don't use inline assembly. But since it's generally abnormal to do either
of
those, it's not generally an issue. The one function that I'm aware which
regularly causes issues with that is enforce(), and there has been some talk of
making it non-lazy, or making a non-lazy version of it, or somehow making the
compiler smart enough to choose whether to make it lazy or not.
In any case, if you want to enable inlining, use the -inline flag. It would be
typical to use that with -release and -O. Don't use it for debug builds though,
since that'll screw with debuggers (just like -O can).
- Jonathan M Davis
Re: inlining
Jonathan M Davis wrote:
On Tuesday 07 December 2010 03:05:28 spir wrote:
Hello,
Does dmd inline when appropriate (eg single-line func)? or is there a
hint keyword? or what else? Eg how to have this inlined:
private bool isPrecomposedHangulSylable (Code code) {
/** whether code is a precomposed Hangul syllable ;-) */
return (code = FIRST_HANGUL_SYLLABLE) (code =
LAST_HANGUL_SYLLABLE); }
C++ has the inline keyword, and it is used only as a hint to the compiler.
The compiler is free to follow it or ignore it as it sees fit, so its
usefulness is debateable. D does _not_ have the inline keyword. It just
leaves it up to the compiler entirely. Note that the -inline flag enables
inlining.
IIRC, no functions which have lazy parameters or include inline assembly
will ever be inlined. And, of course, if a function is long, the compiler
is unlikely to choose to inline it (though maybe it would choose to if the
function is only ever called once - that's up to the inliner).
...
- Jonathan M Davis
There are some other conditions that prevent inlining, it's best to check
for it. iirc also functions with loops, delegate and ref parameters cannot
be inlined for example. I'm not so sure about ref, that may have been
improved since the last time I checked. Perhaps also for some class of
delegates, at least ldc supposedly can inline some functions with delegate
parameters.
Re: inlining
On Tue, 07 Dec 2010 13:44:18 +0100 Lutger Blijdestijn lutger.blijdest...@gmail.com wrote: There are some other conditions that prevent inlining, it's best to check for it. iirc also functions with loops, delegate and ref parameters cannot be inlined for example. I'm not so sure about ref, that may have been improved since the last time I checked. Perhaps also for some class of delegates, at least ldc supposedly can inline some functions with delegate parameters. What do you mean with ref, ref parameters? If yes, why ar they problematic? Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: C Bitfields in D
07.12.2010 11:58, Jonathan M Davis пишет:
Okay. I'm trying to get some C code to be properly callable from some D code,
which naturally involves some extern(C) blocks. One of the types that I have to
deal with looks something like this:
typedef struct
{
unsigned i:1;
} my_struct;
I have no idea how to do such a bitfield in D. Does a std.bitmanip.bitfield
work?
I wouldn't have thought so, but I don't know. What would be the proper way to
create a properly compatible struct in D?
- Jonathan M Davis
I'm under the impression that
struct my_struct
{
mixin(bitfields!(
uint, i, 1,
uint, , 31));
}
should do the trick.
Re: How to exit a process?
06.12.2010 22:11, Adam Ruppe пишет: Is there a thing like C's exit() for a D program? Is simply using C's function good enough? Also take a look at core.runtime.Runtime.terminate()
Re: inlining
spir wrote:
On Tue, 07 Dec 2010 13:44:18 +0100
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote:
There are some other conditions that prevent inlining, it's best to check
for it. iirc also functions with loops, delegate and ref parameters
cannot be inlined for example. I'm not so sure about ref, that may have
been improved since the last time I checked. Perhaps also for some class
of delegates, at least ldc supposedly can inline some functions with
delegate parameters.
What do you mean with ref, ref parameters? If yes, why ar they
problematic?
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
this:
void foo(ref int a) { a++; }
At the time I checked, this function could not be inlined by dmd, which can
cost performance in some cases.
Re: inlining
Lutger Blijdestijn wrote:
spir wrote:
On Tue, 07 Dec 2010 13:44:18 +0100
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote:
There are some other conditions that prevent inlining, it's best to
check for it. iirc also functions with loops, delegate and ref
parameters cannot be inlined for example. I'm not so sure about ref,
that may have been improved since the last time I checked. Perhaps also
for some class of delegates, at least ldc supposedly can inline some
functions with delegate parameters.
What do you mean with ref, ref parameters? If yes, why ar they
problematic?
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
this:
void foo(ref int a) { a++; }
At the time I checked, this function could not be inlined by dmd, which
can cost performance in some cases.
ok I checked it, it seems the dmd has improved in the meantime and is able
to inline this case now.
For reference:
void foo(ref int a ) { a++; }
void bar(int* a ) { a++; }
void main()
{
int a;
foo(a);
bar(a);
}
compile with -profile -inline -O and run it, it will produce a trace.log and
trace.def file. The trace.def contain the optimal order in which to link the
functions, the trace.log file contains a call graph and a table of timings.
(you won't see anything interesting here, because everything is inlined).
It's a great way to check for performance bottlenecks.
Re: C Bitfields in D
I haven't tried but maybe htod can help, try copypasting the code to a
header file and run it through htod. There's also some flags htod can
take to simplify the output, iirc. But maybe htod isn't clever enough
to do bitfields..
On 12/7/10, Stanislav Blinov bli...@loniir.ru wrote:
07.12.2010 11:58, Jonathan M Davis пишет:
Okay. I'm trying to get some C code to be properly callable from some D
code,
which naturally involves some extern(C) blocks. One of the types that I
have to
deal with looks something like this:
typedef struct
{
unsigned i:1;
} my_struct;
I have no idea how to do such a bitfield in D. Does a
std.bitmanip.bitfield work?
I wouldn't have thought so, but I don't know. What would be the proper way
to
create a properly compatible struct in D?
- Jonathan M Davis
I'm under the impression that
struct my_struct
{
mixin(bitfields!(
uint, i, 1,
uint, , 31));
}
should do the trick.
unpacking
Hello D people, Is there a way to unpack an array into local vars, as: auto x = [1,2,3]; a,b,c = x; Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: unpacking
On Tuesday, December 07, 2010 09:29:18 spir wrote: Hello D people, Is there a way to unpack an array into local vars, as: auto x = [1,2,3]; a,b,c = x; No. There is no way to do multiple assignments to the left of an assignment operator. The only way that you can do multiple assignments on one line is to assign multiple variables to the same value. e.g. i = j = k = l; And that's not what you're trying to do. - Jonathan M Davis
free function on arrays language operations
Hello again, I started to be found of defining types which basically are arrays with free functions, instead of creating a struct or class with methods. Not only we still have pseudo-method syntax (for arrays only), but this allows customizing the type when needed. But: is there a way to define functions corresponding to language operations (opEquals, opIndex, toString...) without creating a true type? Thank you, Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: unpacking
spir: Is there a way to unpack an array into local vars, as: auto x = [1,2,3]; a,b,c = x; Not yet, but I have asked this feature for tuples too and maybe someone has appreciated it. Bye, bearophile
Re: free function on arrays language operations
spir: But: is there a way to define functions corresponding to language operations (opEquals, opIndex, toString...) without creating a true type? You may find some trick to do something like that, but it's not how D is supposed to be used. In D operators belong in a struct/class/enum. alias this sometimes helps. Bye, bearophile
Re: C Bitfields in D
Stanislav Blinov:
I'm under the impression that
struct my_struct
{
mixin(bitfields!(
uint, i, 1,
uint, , 31));
}
should do the trick.
But bitfields in C may not use the same alignments used by bitfields!() on DMD
so I think you have to test the sanity of the whole thing for each combination
of D compiler, operating system and C compiler.
Bye,
bearophile
Re: free function on arrays language operations
On Tuesday, December 07, 2010 10:10:31 spir wrote: Hello again, I started to be found of defining types which basically are arrays with free functions, instead of creating a struct or class with methods. Not only we still have pseudo-method syntax (for arrays only), but this allows customizing the type when needed. But: is there a way to define functions corresponding to language operations (opEquals, opIndex, toString...) without creating a true type? No. You need to create an actual type for that sort of thing. Arrays aren't intended to be used for creating types. strings are kind of a special case in that regard, and they're not exactly their own type anyway. - Jonathan M Davis
Re: inlining
On Tue, 07 Dec 2010 16:20:45 +0100
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote:
Lutger Blijdestijn wrote:
spir wrote:
On Tue, 07 Dec 2010 13:44:18 +0100
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote:
There are some other conditions that prevent inlining, it's best to
check for it. iirc also functions with loops, delegate and ref
parameters cannot be inlined for example. I'm not so sure about ref,
that may have been improved since the last time I checked. Perhaps also
for some class of delegates, at least ldc supposedly can inline some
functions with delegate parameters.
What do you mean with ref, ref parameters? If yes, why ar they
problematic?
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
this:
void foo(ref int a) { a++; }
At the time I checked, this function could not be inlined by dmd, which
can cost performance in some cases.
ok I checked it, it seems the dmd has improved in the meantime and is able
to inline this case now.
For reference:
void foo(ref int a ) { a++; }
void bar(int* a ) { a++; }
void main()
{
int a;
foo(a);
bar(a);
}
compile with -profile -inline -O and run it, it will produce a trace.log and
trace.def file. The trace.def contain the optimal order in which to link the
functions, the trace.log file contains a call graph and a table of timings.
(you won't see anything interesting here, because everything is inlined).
It's a great way to check for performance bottlenecks.
Right. Tried worked as you say. Thenk for the tip.
denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: C Bitfields in D
bearophile wrote:
Stanislav Blinov:
I'm under the impression that
struct my_struct
{
mixin(bitfields!(
uint, i, 1,
uint, , 31));
}
should do the trick.
But bitfields in C may not use the same alignments used by bitfields!() on DMD
so I think you have to test the sanity of the whole thing for each combination
of D compiler, operating system and C compiler.
Bye,
bearophile
hm... what alignments are you talking about? bitfields template uses the
smallest suitable type for all fields, which is uint for the above
struct. The trouble may come from bit order, mayhaps. bitfields
positions fields in LSb order.
Re: C Bitfields in D
Stanislav Blinov wrote: But bitfields in C may not use the same alignments used by bitfields!() on DMD so I think you have to test the sanity of the whole thing for each combination of D compiler, operating system and C compiler. hm... what alignments are you talking about? bitfields template uses the smallest suitable type for all fields, which is uint for the above struct. The trouble may come from bit order, mayhaps. bitfields positions fields in LSb order. There is almost no guarantee in C (and C++) on how the bitfields are layed out. I had implemented a C++ template solution once just to overcome that lack of layout. We needed to have our bits layed out exactly in certain ways. Ali
Re: C Bitfields in D
Jonathan M Davis Wrote:
Okay. I'm trying to get some C code to be properly callable from some D code,
which naturally involves some extern(C) blocks. One of the types that I have
to
deal with looks something like this:
typedef struct
{
unsigned i:1;
} my_struct;
I have no idea how to do such a bitfield in D. Does a std.bitmanip.bitfield
work?
I wouldn't have thought so, but I don't know. What would be the proper way to
create a properly compatible struct in D?
- Jonathan M Davis
I had some help from htod translating Fuse headers:
https://github.com/he-the-great/Fused/blob/master/src/fuse_common.d#L47
struct my_struct
{
uint __bitfield1;
@property uint i() { return (__bitfield1 0) 0x1; }
@property uint i(uint value) { __bitfield1 = (__bitfield1
0xfffe) | (value 0); return value; }
}
I think I got the copy/past/modify right.
Re: C Bitfields in D
On 12/8/10, Walter Bright newshou...@digitalmars.com wrote: Andrej Mitrovic wrote: I haven't tried but maybe htod can help, try copypasting the code to a header file and run it through htod. There's also some flags htod can take to simplify the output, iirc. But maybe htod isn't clever enough to do bitfields.. htod does bitfields. Give it a try! Cool! But, when is ctod.exe coming out? :p
Re: C Bitfields in D
On 12/8/10, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 12/8/10, Walter Bright newshou...@digitalmars.com wrote: Andrej Mitrovic wrote: I haven't tried but maybe htod can help, try copypasting the code to a header file and run it through htod. There's also some flags htod can take to simplify the output, iirc. But maybe htod isn't clever enough to do bitfields.. htod does bitfields. Give it a try! Cool! But, when is ctod.exe coming out? :p That should have been cpptod. ;)
Re: C Bitfields in D
Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Cool! But, when is ctod.exe coming out? :p That should have been cpptod. ;) As soon as you write it. -- Simen
Re: unpacking
On 07/12/2010 17:29, spir wrote:
Hello D people,
Is there a way to unpack an array into local vars, as:
auto x = [1,2,3];
a,b,c = x;
import std.stdio;
void unpack(A, T...)(out T vars, A data) {
assert (vars.length == data.length);
foreach (i, v; vars) {
vars[i] = data[i];
}
}
void main() {
auto x = [1,2,3];
int a, b, c;
unpack(a, b, c, x);
writefln(%d %d %d, a, b, c);
}
Stewart.
