Byron A Jeff <PICLIST@MITVMA.MIT.EDU> wrote:

> Well I've been working on my own language targeted for micro and
> nano controllers and I addressed the bit issue simular to the
> existing extensions to the C compilers
> ....
> imagine some bit reversal code...
>
> char a,b,i;
>
> i=0;
> while (i<8)
>    b:7-i = a:i;
> endwhile
>
> I find this more powerful than the pointer to a bit personally....

Byron:

As you mentioned, this is the way that many embedded-C compilers
deal with the problem, although most of them use the existing struct
"." notation rather than your ":" notation.

Your method works fine for small bit "arrays" containing fewer
elements than the width of your largest supported numeric type, but
what happens when you want to do the bit-reversal thing with larger
arrays?

Let's say, for example, that you're the kind of guy who tries to
generalize his code as much as possible... You might rewrite that
bit-reversal example as:

    char a,b,i;

    const char w = 8 * sizeof a;    //w holds the width of the
                                    //"array", in bits.

    i=0;
    while (i<w)
        b:w-i-1 = a:i;
    endwhile

If you do it this way, your bit-reversal code won't break when you
later decide that "a" and "b" should be 16-bit ints rather than
8-bit chars.  This is a Good Thing.

Additionally, it allows you to run the bit-reversal code on "arrays"
of any arbitrary width SMALLER than the width of a char, by simply
changing the "w" definition to:

    const char w = 5;   // we're only interested in the low 5 bits
                        // of the "a" and "b" arrays.

This is another Good Thing... Maybe even a Very Good Thing.

Ok...

So far, your arrangement seems just as useful as bit pointers, and --
for programmers who aren't familiar enough with pointers to recognize
and use all the common idioms -- it may be, as you say, "more
powerful than the pointer to a bit".

But...

What happens when your "array" is larger than the largest numeric
type supported by your compiler?  For example, what if you want to
modify the routine to handle an "array" of 24 bits?

Suddenly, it doesn't look so good (even if your language allows
arrays of chars):

    char a[3], b[3], i;

    const char e = 8 * sizeof a[0]; // e holds the width of each
                                    // char, in bits.

    const char n = sizeof a;        // n holds the number of chars
                                    // in the array.

    const char w = e*n;             // w holds the total number of
                                    // bits in the array.

    i=0;
    while (i<w)
        b[n - i/e - 1]:e - i%e - 1 = a[i/e]:i%e;
    endwhile

If you were presented with this code and asked to explain what it
does, how long would it take you to figure it out?

Yeah, me too.

Nevertheless, the routine WILL work for arbitrarily-large arrays of
chars, and anyone who wrote a function like that last one could argue
that since it IS so flexible, no one else will ever have to see it;
other programmers will just use it without having to know how it
works.

"After all," the argument would go, "math libraries are often
inscrutable, too, but no one complains about THEM."

I might even be convinced by this argument... Until I tried to use
the function on an array of bits that wasn't an exact multiple of the
width of a char.

Let's say I wanted to use an array of only twenty bits.  In the first
example, this was accomplished by simply hard-coding "w", so I'd make
the same change here, namely:

    const char w = 20   // we're only interested in the low 20
                        // bits of the "a" and "b" arrays.

and I'd be unhappily astonished by the results.

Now...

If real bit arrays were allowed, your original program could be
expressed like this:

    bit a[8], b[8];
    char i;

    const char w = sizeof a;    //w holds the width of the
                                //array, in bits.

    i = 0;
    while (i < w)
        b[w-i-1] = a[i];
    endwhile

which looks almost identical to your original easy-to-follow example.

The difference, though, is that you can use this routine for arrays
of ANY arbitrary size.

I dunno... Seems as though "real" arrays of bits are still a pretty
powerful method for doing this sort of thing.

Just my opinion; I could be wrong.

-Andy

=== Andrew Warren - fastfwd@ix.netcom.com                 ===
=== Fast Forward Engineering - Vista, California          ===
===                                                       ===
=== Custodian of the PICLIST Fund -- For more info, see:  ===
=== http://www.geocities.com/SiliconValley/2499/fund.html ===