Fwd: How do you bitwise operations in Ada '83 and '95

Fwd: How do you bitwise operations in Ada '83 and '95

[Marius Amado-Alves]

>> Note that I don't do bit shifting. Instead I multiply or divide by a
>> magnitude. I don't think bit shifting is portable.
>
> Why should language defined Interfaces.Shift_Right,
> Interfaces.Shift_Right_Arithmetic, Rotate etc. be any less
> portable than language defined arithmetic, as implemented
> by the same compiler

By the same compiler on the same platform yes. For data passed  
between different systems, possibly compiled with different  
compilers, I am not sure. I am not an expert on this part of the RM.  
To me bit shifting is a positional thing. Surely positions differ  
across systems. So I programmed defensively. (In fact I think my  
program would work on a platform of any numerical base, not just  
binary, although this is academic I guess.)

Fwd: How do you bitwise operations in Ada '83 and '95

[tmoran]

>To me bit shifting is a positional thing. Surely positions differ
   And why is it again that you want to DIY instead of using a record
specification and thus leaving it to the compiler to generate fast,
correct, code to handle the shifting and masking?  (Since the Subject line
mentions "bitwise" operations, you presumably are multiplying and dividing
by powers of two on a binary machine, right?)

Re: How do you bitwise operations in Ada '83 and '95

[Marius Amado-Alves]

>> To me bit shifting is a positional thing. Surely positions differ
>    And why is it again that you want to DIY instead of using a  
> record...

I need dates in a 64-bit string. Calendar_64 does just that.

Why I need dates in a 64-bit string? Short version of a long story:  
to store then in Mneson vertices as 64-bit integers.

Why I use a modular type instead of a record with rep. clauses? More  
practical. (And I think safer, I think rec. rep. clauses are not as  
strongly required by the RM to be met by the implementation, which is  
yes very strange, but that's the reading of the RM I have, maybe I am  
wrong.) On the practical side, I particularly like that the  
predefined binary relations for the modular Time type can be used as is.

Re: How do you bitwise operations in Ada '83 and '95

[tmoran]

>Why I use a modular type instead of a record with rep. clauses? More
>practical. (And I think safer, I think rec. rep. clauses are not as
>strongly required by the RM to be met by the implementation, which is
   If you really want to be portable to a compiler meeting the absolute
minimum standard, then you are, of course, doing your own 64 bit
arithmetic, since both Integer and System.Max_Binary_Modulus are only
required to be 16 bits.
   Ada is designed to be highly readable and to aid in creating correct
programs.  Surely a record rep clause, and then simple usage of its
components, is more readable, and more likely to be correct, and even more
likely to generate optimized code, than source code littered with complex
arithmetic expressions.
   When I used languages other than Ada, I thought of a compiler as a tool
to convert my source code to binary.  With Ada, though, I think of the
compiler as an assistant, doing the scut work (like shifting and masking
in this case) and watching to tell me of any obvious errors.  It's a
different world view.

Re: How do you bitwise operations in Ada '83 and '95

[Simon Wright]

tmoran@acm.org writes:

>    Ada is designed to be highly readable and to aid in creating
> correct programs.  Surely a record rep clause, and then simple usage
> of its components, is more readable, and more likely to be correct,
> and even more likely to generate optimized code, than source code
> littered with complex arithmetic expressions.

Unless you are concerned with endian-independence, of course, when the
rep clause becomes highly incomprehensible. I have a feeling that
shift&mask ends up more understandable and reviewable.

Re: How do you bitwise operations in Ada '83 and '95

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> tmoran@acm.org writes:
>
>>    Ada is designed to be highly readable and to aid in creating
>> correct programs.  Surely a record rep clause, and then simple usage
>> of its components, is more readable, and more likely to be correct,
>> and even more likely to generate optimized code, than source code
>> littered with complex arithmetic expressions.
>
> Unless you are concerned with endian-independence, of course, when the
> rep clause becomes highly incomprehensible. 

Not in Ada 2005; 'Bit_Order is required to work "nicely" to make
endian-independent rep clauses. See AI95-00133 and
http://www.ada-auth.org/ai-files/grab_bag/bitorder.pdf.

However, not even GNAT implements this yet. We need to put more
pressure on the compiler vendors. Or be more patient :).

> I have a feeling that shift&mask ends up more understandable 

Never.

> and reviewable.

In Ada 95, maybe. In Ada 2005, not.

-- 
-- Stephe

Re: How do you bitwise operations in Ada '83 and '95

[Simon Wright]

Stephen Leake <stephen_leake@acm.org> writes, responding to me:

>> I have a feeling that shift&mask ends up more understandable 
>
> Never.
>
>> and reviewable.
>
> In Ada 95, maybe. In Ada 2005, not.

Really, understandable and reviewable are very similar, so I don't see
how something could be (possibly) more reviewable while never more
understandable.

Seriously, the C

  field = (longword >> 15) & 0x3f;

is pretty clear.

I didn't know about the 05 change to 'Bit_Order, sounds good, not much
help with the current project though!

Re: How do you bitwise operations in Ada '83 and '95

[tmoran]

> Seriously, the C
>
>   field = (longword >> 15) & 0x3f;
>
> is pretty clear.
Not as clear, and more error prone than
    field := soccer_schedule.location;
Not to mention that "field" could be of type "soccer_field_ids" in Ada,
thus allowing the compiler to check that you aren't assigning the hour of
the game to the variable "field", rather than of type "Unsigned_96" which
prevents the compiler from helping you guard against error.

Re: How do you bitwise operations in Ada '83 and '95

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@acm.org> writes, responding to me:
>
>>> I have a feeling that shift&mask ends up more understandable 
>>
>> Never.
>>
>>> and reviewable.
>>
>> In Ada 95, maybe. In Ada 2005, not.
>
> Really, understandable and reviewable are very similar, so I don't see
> how something could be (possibly) more reviewable while never more
> understandable.

Hmm. To me, "understandable" means "expressed in terms I am familiar
with, using idioms I am familiar with, and unambiguous". Or something
like that.

While "reviewable" means "traceable to source documentation".

So if I am familiar with the Ada 95 idiom for endianness-independent
rep clauses, they are "understandable". But because they are complex,
they may be less reviewable. I've never done a _formal_ review (trace to
source docs) of any software, so I'm on shaky ground here.

> Seriously, the C
>
>   field = (longword >> 15) & 0x3f;
>
> is pretty clear.

At the bit level, yes. But if the 7 bits are supposed to represent
some object, actual names would be far preferable.

-- 
-- Stephe

Re: How do you bitwise operations in Ada '83 and '95

[Simon Wright]

Stephen Leake <stephen_leake@acm.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> Stephen Leake <stephen_leake@acm.org> writes, responding to me:
>>
>>>> I have a feeling that shift&mask ends up more understandable 
>>>
>>> Never.
>>>
>>>> and reviewable.
>>>
>>> In Ada 95, maybe. In Ada 2005, not.
>>
>> Really, understandable and reviewable are very similar, so I don't
>> see how something could be (possibly) more reviewable while never
>> more understandable.
>
> Hmm. To me, "understandable" means "expressed in terms I am familiar
> with, using idioms I am familiar with, and unambiguous". Or
> something like that.
>
> While "reviewable" means "traceable to source documentation".
>
> So if I am familiar with the Ada 95 idiom for endianness-independent
> rep clauses, they are "understandable". But because they are
> complex, they may be less reviewable. I've never done a _formal_
> review (trace to source docs) of any software, so I'm on shaky
> ground here.

To me, code review is a process exceuted by people whose intention is
to ensure that the code does the right thing. Part of that is to check
that it's meeting its requirements, some of the requirements are
customer-imposed functional ones. So the people have to be able to
understand the code, and it helps if it's obviously doing the right
thing.

There are ways of writing Ada 95 rep clauses that were
endian-indepednent, I found them very clever but perhaps too clever.

>> Seriously, the C
>>
>>   field = (longword >> 15) & 0x3f;
>>
>> is pretty clear.
>
> At the bit level, yes. But if the 7 bits are supposed to represent
> some object, actual names would be far preferable.

I hope no one thought I was proposing that this bit twiddling (C or
Ada) should get out of package bodies!