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