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))) ]

"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...

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))) ]

"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

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))) ]

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))) ]

"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 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];

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

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