www.digitalmars.com         C & C++   DMDScript  

D - Suggestion: 'bits' property

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sometimes you have to get certain bits out of an expression.  It's ugly
to code...why not make it a property of the variable?  That is, add a
property that slices certain bits out of an integer (or any type,
frankly):

    int orig = 0x01234567;
    int field = orig.bits(0,7);  // field now equals 0x00000067
    field = orig.bits(8,15);     // field now equals 0x00000045

Frankly, if it wouldn't create ambiguity in the compiler, I would like
to use syntax like array slicing:

    field = orig.bits[16..19];    // field now equals 0x00000003

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
May 09 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CDAD769.7A60BB24 deming-os.org...

 Frankly, if it wouldn't create ambiguity in the compiler, I would like
 to use syntax like array slicing:

     field = orig.bits[16..19];    // field now equals 0x00000003
I like the idea! And since bit arrays are already present in the language, it seems even more logical...
May 09 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel Minayev wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CDAD769.7A60BB24 deming-os.org...

 Frankly, if it wouldn't create ambiguity in the compiler, I would like
 to use syntax like array slicing:

     field = orig.bits[16..19];    // field now equals 0x00000003
I like the idea! And since bit arrays are already present in the language, it seems even more logical...
I wasn't suggesting precisely a bit array (but that might work, see below). Technically, it's just a shift, with no cast to a bit array. However, it might not be bad to have the language do implicit casts from bit arrays to integer types...with checks to make sure that the the size is ok: int orig = 0x01234567; bit[] b = orig.bits; int field = b[20..31]; -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
May 09 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
I like where this thread is headed.  Runtime bitfields!!  Maybe this will
help greatly with writing compression or other bit twiddling routines.  It
would also be an opportunity for the compiler to gain some information about
bit usage, so it could optimize say
int a;
a.bits(0,15) = short1;
a.bits(16,31) = short2;
into one 32-bit write; optimize mask operations etc.

Sean

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CDAE4DA.4B7BA704 deming-os.org...
 Pavel Minayev wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CDAD769.7A60BB24 deming-os.org...

 Frankly, if it wouldn't create ambiguity in the compiler, I would like
 to use syntax like array slicing:

     field = orig.bits[16..19];    // field now equals 0x00000003
I like the idea! And since bit arrays are already present in the
language,
 it seems even more logical...
I wasn't suggesting precisely a bit array (but that might work, see
below).
 Technically, it's just a shift, with no cast to a bit array.

 However, it might not be bad to have the language do implicit casts from
bit
 arrays to integer types...with checks to make sure that the the size is
ok:
     int orig = 0x01234567;
     bit[] b = orig.bits;
     int field = b[20..31];
May 10 2002
prev sibling parent Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CDAD769.7A60BB24 deming-os.org...
 
 
Frankly, if it wouldn't create ambiguity in the compiler, I would like
to use syntax like array slicing:

    field = orig.bits[16..19];    // field now equals 0x00000003
I like the idea! And since bit arrays are already present in the language, it seems even more logical...
Seconded, thirded, and fourthed. ushort pixel; red = pixel.bits[11..15] << 3; green = pixel.bits[ 5..10] << 2; blue = pixel.bits[ 0.. 4] << 3; Far cleaner and clearer than the usual and-masking. -Russell B
May 10 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CDAD769.7A60BB24 deming-os.org...
 Sometimes you have to get certain bits out of an expression.  It's ugly
 to code...why not make it a property of the variable?  That is, add a
 property that slices certain bits out of an integer (or any type,
 frankly):

     int orig = 0x01234567;
     int field = orig.bits(0,7);  // field now equals 0x00000067
     field = orig.bits(8,15);     // field now equals 0x00000045

 Frankly, if it wouldn't create ambiguity in the compiler, I would like
 to use syntax like array slicing:

     field = orig.bits[16..19];    // field now equals 0x00000003

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]
A very interesting idea indeed! There might be a concern that all these (admittedly super handy) properties might cause code bloat to the language though? If I write a small program and never use the bits property, or the sorting properties of arrays for that matter, will the code associated with these properties still be included in the program? But that aside I like it, and bit extracting code isn't big anyhow. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
May 09 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
OddesE wrote:

 There might be a concern that all these (admittedly
 super handy) properties might cause code bloat to
 the language though? If I write a small program and
 never use the bits property, or the sorting properties
 of arrays for that matter, will the code associated
 with these properties still be included in the program?
We do need to be careful about this - but bit extracting is not very hard. For the record, here is my proposal for the Standard Implementation (tm) of bit shifting: var.bits[n..m] May be implemented as (assuming that 'type' is the type of 'var'): var << (type.size*8-1-m) >>> (type.size*8-1-m+n); At least, I think my math is right here...don't have time to check it too closely. -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
May 09 2002
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
OddesE wrote:

 There might be a concern that all these (admittedly
 super handy) properties might cause code bloat to
 the language though? If I write a small program and
 never use the bits property, or the sorting properties
 of arrays for that matter, will the code associated
 with these properties still be included in the program?
This may be a place for GENERICS. There have been a number of places where I (or somebody else) has suggested syntax sugar, and then provided a formula for the expanded code that implements it. If a library of these expansions were available and something that could be either included in the standard library or wrapped into every compiler, then compilers could support fancy syntax sugar while using a standard, cross-compiler implementation of it. So in this theory, generics are not blocks of code like normal functions...they are patterns that expand to code, which the compiler can simply do pattern replacement on. So lemme play with a really ugly first pass at a definition of a generic, inspired by the syntax bison/yacc uses: generic getbits as expression: expression '.' "bits" '[' expression ".." expression ']' { ( ($1) << (($1).type.size*8-1-($5)) >>> (($1).type.size*8-1-($5)+($7))) } ; The idea is that it declares a generic that may be used as an "expression". Other contexts might be generics that could be used as "statements" or other things. To match this generic, you must find a valid expression of some sort, followed by a dot, followed by "bits", followed by the open bracket, followed by a valid expression, the ".." operator, another expression, and finally a closing bracket. You are telling it that that pattern may be replaced with the pattern within the braces. The $1, $5, and $7 tell the compiler to replace those respective elements of the pattern into the expression; thus $1 is the first expression, $5 is the second, and $7 is the last. Problems: * Need to declare associativity. Properties have left-associativity * Need to declare precedence. This should have the same precedenc as other properties. * Need to substitute in $1, $5, $7 by VALUE, not by expression, so that foo.bits[bar() .. baz()] doesn't run bar() or baz() multiple times. Or we need a syntax to use temporary variables. Actually, to solve both the associativity and the precedence issue, it would be cool to be able to declare something "generic x as property", meaning that you're just declaring a new type of property... -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
May 09 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CDAD769.7A60BB24 deming-os.org...
 Sometimes you have to get certain bits out of an expression.  It's ugly
 to code...why not make it a property of the variable?  That is, add a
 property that slices certain bits out of an integer (or any type,
 frankly):

     int orig = 0x01234567;
     int field = orig.bits(0,7);  // field now equals 0x00000067
     field = orig.bits(8,15);     // field now equals 0x00000045

 Frankly, if it wouldn't create ambiguity in the compiler, I would like
 to use syntax like array slicing:

     field = orig.bits[16..19];    // field now equals 0x00000003
It's an intriging idea. I added it to the list of possible 2.0 features. Basically, I was thinking of altering it to being able to cast a slice of a bit array into an integral type.
May 10 2002
parent "Robert W. Cunningham" <rcunning acm.org> writes:
Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CDAD769.7A60BB24 deming-os.org...
 Sometimes you have to get certain bits out of an expression.  It's ugly
 to code...why not make it a property of the variable?  That is, add a
 property that slices certain bits out of an integer (or any type,
 frankly):

     int orig = 0x01234567;
     int field = orig.bits(0,7);  // field now equals 0x00000067
     field = orig.bits(8,15);     // field now equals 0x00000045

 Frankly, if it wouldn't create ambiguity in the compiler, I would like
 to use syntax like array slicing:

     field = orig.bits[16..19];    // field now equals 0x00000003
It's an intriging idea. I added it to the list of possible 2.0 features. Basically, I was thinking of altering it to being able to cast a slice of a bit array into an integral type.
I'd also like to see it on the LHS: SomeHardwareRegister.bits[3..10] |= 0x0F; -BobC
May 10 2002