Re: Bit manipulation

["Ken Garlington" <Ken.Garlington@computer.org>]

"Sandro Binetti" <sandrobinetti@my-deja.com> wrote in message
news:8udr5g$d6t$1@nnrp1.deja.com...
: In article <dale-E44FBB.07363509112000@news-server>,
:   Dale Stanbrough <dale@cs.rmit.edu.au> wrote:
: >
: > The answer to the first argument is that you use C to call Unix
: routines
: > because either
:
: [ ... snip ...]
:
: OK! You're quite right! This first case is meaningless.
:
: >
: > The second argument, that you -have- to use low level manipulation
: > in C, is not supported by any examples.
:
: There are, IMHO, two different languages:
: 1) the language used by hardware engineers
: 2) the (O.O.) programming languages used by the software developpers
: that should use the hardware devices sub 1)
:
: The language sub 1) is, quite often, bit-manipulation oriented (mask
: the 4 MSB to obtain XXX, shift twice leftmost in the register YYY to
: set the device status in ZZZ mode, and so on ...)

Hardware engineers often speak this way -- if their experience is limited to
C and assembly, where those are the only features open to them. On the other
hand, it's not hard to teach them to actually say what they want (in turn,
"XXX is defined as the Y low-order bits," "set register YYY to four times
it's current value to active ZZZ mode," and so on ...)

: The language sub 2), say ADA, has to make an abstraction of these
: hardware specifications, or, simply, use them?

Hopefully, it both uses _and_ abstracts them, particularly if they are
likely to change.

: Is it correct, in a teamwork made of a lot of engineers and programmers
: that exchange documentation each other, arbitrarily "upset" a bit-
: oriented specification, given as a starting point for a subsequent
: software developement, in order to "match" ADA high-level point of view?

Not where I work! You confuse the concept of a bit-oriented specification
(e.g., "Bits 7-9 of Register FOO are used to set the error code") with the
operations needed to manipulate FOO. In Ada, I simply describe FOO with a
record representation specification, usually pulled almost verbatim from the
hardware specification. Then, I let the compiler worry about the operations
needed to manipulate it for a given target architecture (and, yes, we have
cases where the target changes, but the hardware interface doesn't).

Perhaps a specific example would help. I searched the Internet for a "status
register layout" and found the following:

http://www.devresource.hp.com/devresource/Docs/Refs/IA64ISA/fp_program3.html
#79426

(You may need to unwrap the URL if it is split across multiple lines).

Here's an Ada package that (semi-)describes this status register:

package Floating_Point_Status_Register is

  -- I'm too lazy to look up the bit-ordering, so I'll just assume...
  type Trap_Options_Type is (
    Inexact_Disabled,
    Underflow_Disabled,
    Overflow_Disabled,
    Zero_Divide_Disabled,
    Denormal_Unnormal_Operand_Disabled,
    Invalid_Operation_Disabled
    );

  type Traps_Type is array (Trap_Options_Type) of Boolean;
  pragma Pack (Traps_Type);

  -- I'm going to ignore the actual layout of status fields
  -- in the interest of time...
  type Status_Field_Type is range 0 .. 16#1FFF#;
  for Status_Field_Type'Size use 13;

  type Reserved_Field_Type is range 0 .. 8#77#;
  for Reserved_Field_Type'Size use 6;

  type Object_Type is record
    Reserved           : Reserved_Field_Type;
    Alternate_Status_3 : Status_Field_Type;
    Alternate_Status_2 : Status_Field_Type;
    Alternate_Status_1 : Status_Field_Type;
    Main_Status        : Status_Field_Type;
    Traps              : Traps_Type;
  end record;

  for Object_Type use record
    Reserved           at 0 range 0 .. 5;
    Alternate_Status_3 at 0 range 6 .. 18;
    Alternate_Status_2 at 0 range 19 .. 31;
    Alternate_Status_1 at 0 range 32 .. 44;
    Main_Status        at 0 range 45 .. 57;
    Traps              at 0 range 58 .. 63;
  end record;
  for Object_Type'Size use 64;

  function Object return Object_Type;

  procedure Set (Object : in Object_Type);

end Floating_Point_Status_Register;


Now, let's say I want to test the Traps field to see if Underflow is
disabled and Overflow isn't. The average programmer attempting to write C in
Ada83 might decide to do the following:

with Floating_Point_Status_Register;
procedure C_Coder_Test is
  package FPSR renames Floating_Point_Status_Register;
  use FPSR.;

  Under_Over_Mask : constant FPSR.Traps_Type :=
    (false, true, true, false, false, false);
  Under_Over_Test : constant FPSR.Traps_Type :=
    (false, true, false, false, false, false);
  Register : FPSR.Object_Type;

begin
  Register := FPSR.Object;
  if (Register.Traps and Under_Over_Mask)
    = Under_Over_Test then
    null; -- whatever
  end if;
end;


On the other hand, the average Ada83 programmer might write:

with Floating_Point_Status_Register;
procedure Test is
  package FPSR renames Floating_Point_Status_Register;
  use FPSR;
  Register : constant FPSR.Object_Type := FPSR.Object;
begin
  if Register.Traps(Underflow_Disabled) and not
    Register.Traps(Overflow_Disabled) then
    null; -- whatever
  end if;
end;


It is left as an exercise which solution is "better" in a software
engineering sense. :)

: Of course, a correctly analized problem has to be faced in a "high-
: level" way, this is the case of certain kind of systems developped
: inside the O.O. paradigm constraints. But, how to face a low-level
: explained problem? Using a low-level language?

Nope, use the high-level features of a language expressly designed to
support bit-oriented hardware protocols.

There are certainly cases where explicit bit-level operations (and, or,
xor...) are useful, such as the encryption example previously cited, and in
fact Ada83 implements them directly for arrays of Boolean. You can also
convert most other types in Ada83 to Boolean arrays, although you do have to
be careful to minimize portability effects. Ada95 provides additional
capabilities with modular types, as previously mentioned.