From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8309f2bc055237c4 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Bit manipulation Date: 2000/11/09 Message-ID: X-Deja-AN: 691623232 References: <8u8v6n$b7o$1@nnrp1.deja.com> <2WTH$pdrCfOd@eisner.decus.org> <8ub6kt$6nd$1@nnrp1.deja.com> <8ubeq8$cgm$1@nnrp1.deja.com> <8ubld2$hdd$1@nnrp1.deja.com> <8udr5g$d6t$1@nnrp1.deja.com> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 973779885 216.215.73.83 (Thu, 09 Nov 2000 08:24:45 CST) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Thu, 09 Nov 2000 08:24:45 CST Newsgroups: comp.lang.ada Date: 2000-11-09T00:00:00+00:00 List-Id: "Sandro Binetti" wrote in message news:8udr5g$d6t$1@nnrp1.deja.com... : In article , : Dale Stanbrough 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.