Bit manipulation

Bit manipulation

[Sandro Binetti]

 Hi,
is there anyone who can help me with bit manipulation on objects like
integers or character?

Which way may I shift bits, or maskerade them?

--
Ciao, Sandro


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[gdemont]

> is there anyone who can help me with bit manipulation on objects like
> integers or character?
>
> Which way may I shift bits, or maskerade them?

Look for modular types (e.g. type byte is mod 2**8 and the
types in Interfaces package (unsigned_8 etc.)). With
them you can "and", "or", "not", "xor" and shift.

Look at... http://www.adapower.com/rm95/index.html

HTH
_____________________________________________
Gautier  --  http://members.nbci.com/gdemont/



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Sandro Binetti]

In article <8u9gl2$qbk$1@nnrp1.deja.com>,
  gdemont@my-deja.com wrote:

> Look at... http://www.adapower.com/rm95/index.html

OK! Added to my bookmarks!
Thanks a lot.

--
Ciao, Sandro


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Larry Kilgallen]

In article <8u8v6n$b7o$1@nnrp1.deja.com>, Sandro Binetti <sandrobinetti@my-deja.com> writes:
>  Hi,
> is there anyone who can help me with bit manipulation on objects like
> integers or character?
> 
> Which way may I shift bits, or maskerade them?

Quite often when someone wants to do something like that, they had
formerly programmed in some other language whose ability to define
data types is not so robust as Ada.

Except for the particular situation of changing case of an ASCII
Roman letter (for which Ada95 has built-in capabilities), flipping
a bit in a character is totally meaningless.

If you really meant to blip a bit in a data cell that happens to
be 8 bits wide, then please study record and array declarations
in an introductory Ada text.  If you have to match some external
standard, such as hardware or a program written in another language,
look at the part about representation clauses.

Re: Bit manipulation

[John English]

Larry Kilgallen wrote:
> Except for the particular situation of changing case of an ASCII
> Roman letter (for which Ada95 has built-in capabilities), flipping
> a bit in a character is totally meaningless.

Not so -- consider simple encryption techniques involving xoring
character codes. I'm sure there must be other useful examples.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Bit manipulation

[gdemont]

Larry:

> Quite often when someone wants to do something like that, they had
> formerly programmed in some other language whose ability to define
> data types is not so robust as Ada.

May I remark that the main question is not:
 "I'm stupid and hopeless since I didn't discover until now the benefits
  of this absolutely superior language called Ada, but I still want
  to do these ugly manipulations I'm accustomed to, so how do I do
  them ?".

But:
 "Which way may I shift bits, or maskerade them?"

And your hint about using records, arrays and representation clauses
is completely overkill just for blipping bits! Please give constructive
answers!
______________________________________________________
Gautier  --  http://members.nbci.com/gdemont/gsoft.htm


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Robert Dewar]

In article <8ub6kt$6nd$1@nnrp1.deja.com>,
  gdemont@my-deja.com wrote:
> But:
>  "Which way may I shift bits, or mask them?"
>
> And your hint about using records, arrays and representation
> clauses is completely overkill just for blipping bits! Please
> give constructive answers!

Nope! When someone asks how can I do "xxx" and xxx is a low
level implementation technique, it is always appropriate to
enquire as to what the problem is.

A C programmer is used to shifting and masking as a solution
for all sorts of problems. Now there are cases where such
a solution is appropriate in Ada, which is why the capability
was added in Ada 95, but compared to C, they are few and
far between.

Clearly the underlying question is "how do I do shifts and
masks to achieve xxx", and to accurately answer this question
we need to ask what xxx is. Quite likely the answer will
be "don't use shifts and masks to achieve xxx if you are
writing Ada, instead use yyy".

Of course we could give a simple answer involving the
obvious solution of converting Character'Pos values to
a modular type and then doing shifts and masks in the
normal manner, but that would be a disservice.

I see a *lot* of code that is clearly written by C programmers
and greatly overuses low level bit twiddling techniques that
are appropriate to C but not to Ada.

If someone simply wants to get a job done in the dirtiest
possible fashion, and wants someone else to do the work,
CLA is not the place to expect free help :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Sandro Binetti]

In article <8ubeq8$cgm$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:

> Nope! When someone asks how can I do "xxx" and xxx is a low
> level implementation technique, it is always appropriate to
> enquire as to what the problem is.
>
> A C programmer is used to shifting and masking as a solution
> for all sorts of problems. Now there are cases where such
> a solution is appropriate in Ada, which is why the capability
> was added in Ada 95, but compared to C, they are few and
> far between.

I'm an ADA programmer since 1989; I've written millions of lines of ADA
code, developped systems that, fortunately, runs without "unhandled
exceptions". I say SYSTEMS, not little PROGRAMS, with lines and lines
of generic instantiation, exception handlers, tasks that wait each
other in respect of strict time constraints, and so on.

But the real fact is not this.

My ADA code has, always, a little (very little) part made of "pragma
INTERFACES" to C language, in order to manage certain Unix or Linux
kernel capabilities (curses, for example).

So, once again, the question is the following:

IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS,
WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL-
TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL
MANIPULATION IN C LANGUAGE?

If you can give me a simple answer...
--
Ciao, Sandro


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Dale Stanbrough]

Sandro Binetti wrote:

> My ADA code has, always, a little (very little) part made of "pragma
> INTERFACES" to C language, in order to manage certain Unix or Linux
> kernel capabilities (curses, for example).
> 
> So, once again, the question is the following:
> 
> IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS,
> WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL-
> TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL
> MANIPULATION IN C LANGUAGE?

You use one argument ("i have to use Unix or Linux kernel capabilties")
to bring us to a second argument ("i have to do low level manipulation
in C").

The answer to the first argument is that you use C to call Unix routines
because either

   the ABI is a C like one
      e.g. execv does not have to be written in C, but the calling
      notations use the C language to describe it. Most of the time
      it is also written in C, but this may not always be the case.
      (is the entire POSIX compatability library for VMS written in C?).

   the routine you are calling is in C.
      You call the routines because they are there, and it's cheaper
      than rewriting them. Nothing wrong with that.


The second argument, that you -have- to use low level manipulation
in C, is not supported by any examples. I'm struggling to think up
an example for which this is the case. Could you provide an example?


Dale

Re: Bit manipulation

[Sandro Binetti]

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

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

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?

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?
--
Ciao, Sandro


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Ken Garlington]

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

Re: Bit manipulation

[gdemont]

Sandro Binetti:

> 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 ...)
>
> The language sub 2), say ADA, has to make an abstraction of these
> hardware specifications, or, simply, use them?

The 1)-2) hiatus is very classic because older languages did fit only
for a part of computing (C for bits, Fortran for maths, Pascal for
abstraction).
The good news is that Ada covers 1) as well as 2). In addition, IHMO
Ada95 offers more powerful (read: precise) tools for 1) than C, e.g. .

> 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?

Ideally the "low-level" engineers write their hardware/IO packages in
Ada, the "high-level" ones write their maths, OO etc. in other packages
also in Ada. Finally a "gnatmake the_big_project" to build the whole.

In a funny domain you can see in my 3D sources (URL below - and sorry
for the auto-advertisement...) an example of project where Ada covers
all levels: (1) reprogramming keyboard interrupt, timer interrupt,
drawing pixels for textured objects with heavy use of bit masking and
shifting, (2) rendering, rotations, projections, management of
"universes" and even (3) organizing interactive scenes (at this stage
the Ada source ressembles to a script) and manipulating 3D models
directly stored in large Ada constant arrays (instead of loading a
VRML).

The modularity of Ada allows to combine all levels quite easily.

____________________________________________________
Gautier  --  http://members.nbci.com/gdemont/e3d.htm


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Scott Ingram]

Sandro Binetti wrote:
> 
> 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)
> 
> --
> Ciao, Sandro

In our group, we use VHDL and schematic capture tools that
readily provide an abstract model.  In our case, we
actually have to break down our models to bits so that
the software guys can understand the interface because they
are using C.  Go figure.

-- 
Scott Ingram
Vice-Chair, Baltimore SIGAda
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: Bit manipulation

[Nicolas Brunot]

That's quite interested to read, and illustrate the 'Ada student homework'
thread.
If this kind of post were more often read, perhaps Ada would be more likely
to be used by software companies, and less ruled by unrealistic scholar
fanatics ...

Sandro Binetti a �crit :

> In article <8ubeq8$cgm$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
>
> > Nope! When someone asks how can I do "xxx" and xxx is a low
> > level implementation technique, it is always appropriate to
> > enquire as to what the problem is.
> >
> > A C programmer is used to shifting and masking as a solution
> > for all sorts of problems. Now there are cases where such
> > a solution is appropriate in Ada, which is why the capability
> > was added in Ada 95, but compared to C, they are few and
> > far between.
>
> I'm an ADA programmer since 1989; I've written millions of lines of ADA
> code, developped systems that, fortunately, runs without "unhandled
> exceptions". I say SYSTEMS, not little PROGRAMS, with lines and lines
> of generic instantiation, exception handlers, tasks that wait each
> other in respect of strict time constraints, and so on.
>
> But the real fact is not this.
>
> My ADA code has, always, a little (very little) part made of "pragma
> INTERFACES" to C language, in order to manage certain Unix or Linux
> kernel capabilities (curses, for example).
>
> So, once again, the question is the following:
>
> IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS,
> WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL-
> TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL
> MANIPULATION IN C LANGUAGE?
>
> If you can give me a simple answer...
> --
> Ciao, Sandro
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: Bit manipulation

[gdemont]

> If you can give me a simple answer...

Ada95: you can do everything in Ada (of course, it can be useful to
       re-use parts already programmed in C or Fortran)
Ada83: for certain things like bit manipulations, you have to
       use compiler-dependent libraries or interface with bits
       of code in C.
HTH
______________________________________________________
Gautier  --  http://members.nbci.com/gdemont/gsoft.htm

PS: so, if your instructor... bla bla.. you should... bla bla
bla... the true Ada programmers do... bla bla... your homework
assignment... bla bla... never do that... bla bla bla bla...
find a good book and read it... bla bla...
PPS: just kidding - from a pure user.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Ken Garlington]

: Ada83: for certain things like bit manipulations, you have to
:        use compiler-dependent libraries or interface with bits
:        of code in C.

I've done huge numbers of bit manipulations in Ada83 without doing either of
these options.

Re: Bit manipulation

[Larry Kilgallen]

In article <yjpO5.8905$pq3.719737@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> writes:
> : Ada83: for certain things like bit manipulations, you have to
> :        use compiler-dependent libraries or interface with bits
> :        of code in C.
> 
> I've done huge numbers of bit manipulations in Ada83 without doing either of
> these options.

Perhaps what you have written would not be portable to another compiler.
Perhaps that is immaterial in your problem domain.  It is in one of mine.

But now I have an additional problem domain where portability becomes
more important, so I am happy the effort went into Ada95.

Larry Kilgallen
Ada83 programmer

Re: Bit manipulation

[Ken Garlington]

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:4bHjnjxVodhb@eisner.decus.org...
: In article <yjpO5.8905$pq3.719737@news.flash.net>, "Ken Garlington"
<Ken.Garlington@computer.org> writes:
: > : Ada83: for certain things like bit manipulations, you have to
: > :        use compiler-dependent libraries or interface with bits
: > :        of code in C.
: >
: > I've done huge numbers of bit manipulations in Ada83 without doing
either of
: > these options.
:
: Perhaps what you have written would not be portable to another compiler.
: Perhaps that is immaterial in your problem domain.  It is in one of mine.

So far, it's survived five compilers (TeleSoft, Tartan, Alsys, Green Hills,
Texas Instruments) and four processors (1750, 80x86, PowerPC, C67) with
little or no modifications required - see, for example:

http://www.lmaeronautics.com/news/press/jsf/jsfpr000531.html

See also the C_Coder_Test procedure I posted elsewhere in this thread, which
does (unncessary) bit masking, etc. It should work on just about any
compiler (Ada83 or Ada95), as far as I know.

Re: Bit manipulation

[Ken Garlington]

"Sandro Binetti" <sandrobinetti@my-deja.com> wrote in message
news:8ubld2$hdd$1@nnrp1.deja.com...

: So, once again, the question is the following:
:
: IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS,
: WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL-
: TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL
: MANIPULATION IN C LANGUAGE?

I give up - why do you?

Ken Garlington (who has developed and fielded Ada code for complex
uncommercial devices, e.g. MIL-STD-1553B aerospace bus, since 1984 without
once using low level manipulation in C language)

Re: Bit manipulation

[Robert Dewar]

In article <8ubld2$hdd$1@nnrp1.deja.com>,
  Sandro Binetti <sandrobinetti@my-deja.com> wrote:

> IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A
SATELLITE BUS,
> WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR
THESE REAL-
> TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW
LEVEL
> MANIPULATION IN C LANGUAGE?

A simple answer is that you don't! There is almost no legitimate
reason for going to C if you are using Ada 95. As many people
have told you in this thread, modular types give you all
the capabilities you have in C for low level bit twiddling.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[gdemont]

> Of course we could give a simple answer involving the
> obvious solution of converting Character'Pos values to
> a modular type and then doing shifts and masks in the
> normal manner, but that would be a disservice.
>
> I see a *lot* of code that is clearly written by C programmers
> and greatly overuses low level bit twiddling techniques that
> are appropriate to C but not to Ada.
>
> If someone simply wants to get a job done in the dirtiest
> possible fashion, and wants someone else to do the work,
> CLA is not the place to expect free help :-)

I'm not sure that Mr Binetti intends to do dirty things.

After all, the conversions like Character'Pos <-> modular
or signed <-> modular precisely draw the attention about
when you enter the realm of bit twiddling on a certain number
of bits, and when some bit and bit length have a special
meaning. They are verbose enough to be re-found after a while,
and to discourage using them when a "* (2**7)" or a "mod 32" suffices.
The dirty thing would be e.g. to allow bit twiddling on a signed
integer, and this is the cause of fast-rotting code in C or some
Pascals; fortunately Ada95 doesn't allow it and has an elegant and
efficient solution for that issue.

I'm sure the users are adult enough to find the most appropriate
formulations for _their_ problems after some weeks of Ada
programming; therefore hiding the availability of modular types
_is_ a disservice. If one tells them that the only solution to mask
bits is to write 20 lines of records definitions with representation
clauses, they won't use Ada at all, simply!

Gautier


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Larry Kilgallen]

In article <8ubhlh$ejv$1@nnrp1.deja.com>, gdemont@my-deja.com writes:
> 
>> Of course we could give a simple answer involving the
>> obvious solution of converting Character'Pos values to
>> a modular type and then doing shifts and masks in the
>> normal manner, but that would be a disservice.
>>
>> I see a *lot* of code that is clearly written by C programmers
>> and greatly overuses low level bit twiddling techniques that
>> are appropriate to C but not to Ada.
>>
>> If someone simply wants to get a job done in the dirtiest
>> possible fashion, and wants someone else to do the work,
>> CLA is not the place to expect free help :-)
> 
> I'm not sure that Mr Binetti intends to do dirty things.

Nor was anyone else, and there are even points where Ada experts
will disagree as to what "dirty" means.

The point is to make the discussion more full, and perhaps we will
all learn about an environment where bit masking is required (such
as the stream cipher case alluded to by John English).  Perhaps we
will learn that careful type declaration will "totally solve" the
problem at hand.  Or perhaps we will learn something unanticipated.

Re: Bit manipulation

[Robert Dewar]

In article <fEMfmNb1Un8J@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> The point is to make the discussion more full, and perhaps we
> will all learn about an environment where bit masking is
> required (such as the stream cipher case alluded to by John
> English).

> Perhaps we will learn that careful type declaration will
> "totally solve" the problem at hand.  Or perhaps we will learn
> something unanticipated.

Very nicely put! Indeed the point here is to learn as much
about the problem as possible, so that the solution space can
be explored in the most effective manner.

La
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Lao Xiao Hai]

Robert Dewar wrote:

>
> Very nicely put! Indeed the point here is to learn as much
> about the problem as possible, so that the solution space can
> be explored in the most effective manner.

As you have pointed out many times Robert, Ada was never intended
to be a convenient language for writing programs.  It is more intended
for responsibly communicating the intended goal of the program with
the fewest errors.   Ease of writing gives way to ease of reading.

Ada is designed so most constructs are, by default, safe.   Therefore,
many convenient idioms common to less rigorous languages such as
automatic
type conversion, automatic promoting of a type,  no checking at all
on the mode or type of a parameter, etc., are avoided by Ada.  On
the other hand, it is quite possible to take a language in which the
default
for every construct is safe and relax the default to less safe.  It is
not
as easy when the default is unsafe (e.g., C and, to a somewhat lesser
extent,
C++) to override that and make the code more safe.

Bit manipulation is simply not that difficult in Ada.   And it does not
even
require overrding the default safety of the language, especially in Ada
95.
As has been noted in other postings, even Ada 83 provided
straightforward
solutions to this, albeit with the requirement that one abide by the
rules of
the language and make absolutely clear that what is being coded is
exactly what is intended.

Richard Riehle

Re: Bit manipulation

[Robert Dewar]

In article <8ubhlh$ejv$1@nnrp1.deja.com>,
  gdemont@my-deja.com wrote:
> I'm sure the users are adult enough to find the most
appropriate
> formulations for _their_ problems after some weeks of Ada
> programming; therefore hiding the availability of modular
types
> _is_ a disservice.


I simply disagree, I am talking about lots of code that I
see written by professional programmers who do not understand
how to do things in Ada. One of the functions of CLA should
be to try to show people how things are done in Ada.

The idea that being an adult guarantees that people know
what they are doing, and that they know the right semantic
level to frame their questions at, is misguided. In fact it
is often VERY difficult to know what semantic level to
frame a question at to get the right answer.

The point is that modular types are occasionally, but only
occasionally the right way of doing things in Ada. C
programmers are used to using this low level approach
all the time, because they do not have alternatives (actually
even in C, I find that programmers often do not use bitfield
specs, simply because they don't know this valuable feature
of the C language).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[gdemont]

> > programming; therefore hiding the availability of modular
> types
> > _is_ a disservice.
>
> I simply disagree, I am talking about lots of code that I
> see written by professional programmers who do not understand
> how to do things in Ada. One of the functions of CLA should
> be to try to show people how things are done in Ada.

The best way would be to write that there are such and such
ways, and, as you wrote, ask for details about the problem
to implement. Of course, also say that such method is safer
than such one which is maybe faster to program. But concealing
a feature for moral reasons is a big disservice to the language,
doubly: 1) it make believe (here) that C is necessary for low-level
elementary operations; 2) the interfacing is always fragile
and make ask: "finally, why did we code the rest in Ada ?".

> The idea that being an adult guarantees that people know
> what they are doing, and that they know the right semantic
> level to frame their questions at, is misguided.

I did not mean that if they are adults, they are good programmers.
Simply, a mediocre programming will be at least much more reliable
(if not safe) in Ada. In various Ada forums/lists, I see sometimes
a part of code coming even from "safety-critical" area, where
the guy believes that a feature (typically modular types) doesn't
exist in Ada, then uses unchecked_conversion on pointers and/or
a complicated interface with a "@a#$s++{--x;{}}" - like piece of C.
In addition, the code doesn't work and the guy concludes that Ada
is really useless (instead of seeing that _he_ is hopeless ;-).

G.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Redryder]

Hey,
 I have another question concerning bit manipulation.
I need to swap the bits in a 32-bit word.  I used a
packed boolean array.  It works well enough, but
it does require looping over the array indices.  Is there
a better way to do this?
Oh, I've framed the task correctly!  This is in a serial
message that goes to a "legacy" system requiring that
the bits are swapped. I have more than 40 different
messages each having similar bit fields in the message.
Still, the bit fields are not the same width or position
from message to message.  There are a number of them
that change position and meaning.
I've been using Ada for a year or so now.  I was using
C/C++.  Personally, if you are looking for safe code,
I think Ada95 is a good answer.
John

Re: Bit manipulation

[Jeff Carter]

Redryder wrote:
> 
> I need to swap the bits in a 32-bit word.

I could perhaps be of more assistance if I knew what you mean by "swap
the bits".

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail

Re: Bit manipulation

[Redryder]

Jeff,
 It goes like this: BIT 0 to BIT 31, BIT 31 to BIT 0 ,  and so on.
John

Jeff Carter wrote:

> Redryder wrote:
> >
> > I need to swap the bits in a 32-bit word.
>
> I could perhaps be of more assistance if I knew what you mean by "swap
> the bits".
>
> --
> Jeff Carter
> "I unclog my nose towards you."
> Monty Python & the Holy Grail

Re: Bit manipulation

[Ken Garlington]

As I recall, there was also an implied desire to avoid a loop. How about:

package Word_Bitstring is
  type Object is array (1 .. 32) of Boolean;
  pragma Pack(Object);

  function Swap (O : Object) return Object;
end Word_Bitstring;

package body Word_Bitstring is
  function Swap (O : Object) return Object is
  begin
    return O(32) & O(31) & O(30) & O(29) &
           O(28) & O(27) & O(26) & O(25) &
           O(24) & O(23) & O(22) & O(21) &
           O(20) & O(19) & O(18) & O(17) &
           O(16) & O(15) & O(14) & O(13) &
           O(12) & O(11) & O(10) & O(09) &
           O(08) & O(07) & O(06) & O(05) &
           O(04) & O(03) & O(02) & O(01);
  end Swap;
end Word_Bitstring;

Seems a little error prone, but it might be reasonably efficient. Try it and
see!

"Redryder" <john.f.anderson@mindspring.com> wrote in message
news:3A0DF35D.729DDE15@mindspring.com...
: Jeff,
:  It goes like this: BIT 0 to BIT 31, BIT 31 to BIT 0 ,  and so on.
: John
:
: Jeff Carter wrote:
:
: > Redryder wrote:
: > >
: > > I need to swap the bits in a 32-bit word.
: >
: > I could perhaps be of more assistance if I knew what you mean by "swap
: > the bits".
: >
: > --
: > Jeff Carter
: > "I unclog my nose towards you."
: > Monty Python & the Holy Grail
:

Re: Bit manipulation

[Jeff Carter]

Redryder wrote:
> 
>  It goes like this: BIT 0 to BIT 31, BIT 31 to BIT 0 ,  and so on.

I take it you want the resulting bit pattern to be the reverse of the
original bit pattern.

This is perhaps best accomplished with packed Boolean arrays, as you can
easily manipulate the individual bits directly, and can change 2 bits
for each value of the loop index.

The fastest but most space-consuming solution would use a look-up table.
Few implementations will support an array of the required size.

You could also use modular types and operations, but this would probably
be less clear than packed Boolean arrays.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail

Re: Bit manipulation

[Robert Dewar]

In article <3A0E3116.83AEC906@acm.org>,
  Jeff Carter <jrcarter@acm.org> wrote:
> The fastest but most space-consuming solution would use a
> look-up table. Few implementations will support an array of
> the required size.


You obviously cannot afford a loop through 32 bits, that's
a gruesomely inefficient implementation. The proper thing
is to establish a look up table of 256 entries (that takes
up only 256 bytes and easily fits into primary cache). Then
program the byte swap (if you are on a machine with a byte
swap instruction like the Power PC, it can be used directly).

If you have a bit more space, you can make a table of
64K 16-bit entries and do 16-bit swaps by table lookup.
That still takes only 128K bytes, which can easily fit
in secondary cache.

Even if you could afford a table of 16 gigabytes for the
full lookup, you would not want to use such an approach,
since you would get cache misses, and probably TLB misses
as well on every access, and it would be horribly slow.

You just HAVE to be sensitive to cache and TLB-miss issues
in modern programming if performance is an issue. Far too
many people have not adjusted their thinking and are still
programming for non-pipelined non-cached machines in their
minds :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[tmoran]

>You just HAVE to be sensitive to cache and TLB-miss issues
>in modern programming if performance is an issue. Far too
  At what point in a programmer's education is this taught these days?

Re: Bit manipulation

[Robert Dewar]

In article <rwDP5.415395$i5.7092109@news1.frmt1.sfba.home.com>,
  tmoran@acm.org wrote:
> >You just HAVE to be sensitive to cache and TLB-miss issues
> >in modern programming if performance is an issue. Far too
> At what point in a programmer's education is this taught
> these days?


Hard to say, since things are very variable. All too often
the answer is not at all. At NYU, we used to have the whole
second year be assembly language programming and machine
and system architecture. But the faculty found that too
much, and it was cut to one semester. Quite a few folks
on the NYU faculty would like to cut out that remaining
semester as a required course, and make it an elective on
the grounds that most people don't need to know low level
stuff, and I am afraid that viewpoint (which I strongly
object to) has already found favor at many major universities,
and people can get an undergraduate degree without this
material ever being taught.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Marc A. Criley]

Robert Dewar wrote:
> 
> In article <rwDP5.415395$i5.7092109@news1.frmt1.sfba.home.com>,
>   tmoran@acm.org wrote:
> > >You just HAVE to be sensitive to cache and TLB-miss issues
> > >in modern programming if performance is an issue. Far too
> > At what point in a programmer's education is this taught
> > these days?
> 
> Hard to say, since things are very variable. All too often
> the answer is not at all. At NYU, we used to have the whole
> second year be assembly language programming and machine
> and system architecture. But the faculty found that too
> much, and it was cut to one semester. Quite a few folks
> on the NYU faculty would like to cut out that remaining
> semester as a required course, and make it an elective on
> the grounds that most people don't need to know low level
> stuff, and I am afraid that viewpoint (which I strongly
> object to) has already found favor at many major universities,
> and people can get an undergraduate degree without this
> material ever being taught.
> 

I certainly must concur with the opposition to that viewpoint.

On many occasions over the course of my career I've had the
debugger display raw memory, registers, and assembly
language to assist the uncovering of bugs.  And all too
frequently when working with someone else, I find that pulling
up these displays to look at low-level information leaves them
glassy eyed and bewildered.  They have little cognizance of
what's going on beneath the surface of the software, be it C,
C++, or Ada.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation

Re: Bit manipulation

[Ken Garlington]

<tmoran@acm.org> wrote in message
news:rwDP5.415395$i5.7092109@news1.frmt1.sfba.home.com...
: >You just HAVE to be sensitive to cache and TLB-miss issues
: >in modern programming if performance is an issue. Far too
:   At what point in a programmer's education is this taught these days?

Well, at the University of Texas at Arlington, it's taught as part of a
graduate course in computer architecture.

Re: Bit manipulation

[tmoran]

>I take it you want the resulting bit pattern to be the reverse of the
>original bit pattern.
>...
>The fastest but most space-consuming solution would use a look-up table.
Swap parts and use a lookup table to swap bits within those parts, eg:
  type Bytes is mod 256;
  type Reversibles is array(1 .. 4) of Bytes;
  Xlate : constant array(Bytes) of Bytes :=
    (16#00000000#,16#10000000#,16#01000000#,16#11000000#,
     16#00100000#,16#10100000#,16#01100000#,16#11100000#,
     16#00010000#,16#10010000#,16#01010000#,16#11010000#,
     16#00110000#,16#10110000#,16#01110000#,16#11110000#,
     16#00001000#,16#10001000#,16#01001000#,16#11001000#,
     16#00101000#,16#10101000#,16#01101000#,16#11101000#,
     16#00011000#,16#10011000#,16#01011000#,16#11011000#,
     16#00111000#,16#10111000#,16#01111000#,16#11111000#,
     16#00000100#,16#10000100#,16#01000100#,16#11000100#,
     16#00100100#,16#10100100#,16#01100100#,16#11100100#,
     16#00010100#,16#10010100#,16#01010100#,16#11010100#,
     16#00110100#,16#10110100#,16#01110100#,16#11110100#,
     16#00001100#,16#10001100#,16#01001100#,16#11001100#,
     16#00101100#,16#10101100#,16#01101100#,16#11101100#,
     16#00011100#,16#10011100#,16#01011100#,16#11011100#,
     16#00111100#,16#10111100#,16#01111100#,16#11111100#,
     16#00000010#,16#10000010#,16#01000010#,16#11000010#,
     16#00100010#,16#10100010#,16#01100010#,16#11100010#,
     16#00010010#,16#10010010#,16#01010010#,16#11010010#,
     16#00110010#,16#10110010#,16#01110010#,16#11110010#,
     16#00001010#,16#10001010#,16#01001010#,16#11001010#,
     16#00101010#,16#10101010#,16#01101010#,16#11101010#,
     16#00011010#,16#10011010#,16#01011010#,16#11011010#,
     16#00111010#,16#10111010#,16#01111010#,16#11111010#,
     16#00000110#,16#10000110#,16#01000110#,16#11000110#,
     16#00100110#,16#10100110#,16#01100110#,16#11100110#,
     16#00010110#,16#10010110#,16#01010110#,16#11010110#,
     16#00110110#,16#10110110#,16#01110110#,16#11110110#,
     16#00001110#,16#10001110#,16#01001110#,16#11001110#,
     16#00101110#,16#10101110#,16#01101110#,16#11101110#,
     16#00011110#,16#10011110#,16#01011110#,16#11011110#,
     16#00111110#,16#10111110#,16#01111110#,16#11111110#,
     16#00000001#,16#10000001#,16#01000001#,16#11000001#,
     16#00100001#,16#10100001#,16#01100001#,16#11100001#,
     16#00010001#,16#10010001#,16#01010001#,16#11010001#,
     16#00110001#,16#10110001#,16#01110001#,16#11110001#,
     16#00001001#,16#10001001#,16#01001001#,16#11001001#,
     16#00101001#,16#10101001#,16#01101001#,16#11101001#,
     16#00011001#,16#10011001#,16#01011001#,16#11011001#,
     16#00111001#,16#10111001#,16#01111001#,16#11111001#,
     16#00000101#,16#10000101#,16#01000101#,16#11000101#,
     16#00100101#,16#10100101#,16#01100101#,16#11100101#,
     16#00010101#,16#10010101#,16#01010101#,16#11010101#,
     16#00110101#,16#10110101#,16#01110101#,16#11110101#,
     16#00001101#,16#10001101#,16#01001101#,16#11001101#,
     16#00101101#,16#10101101#,16#01101101#,16#11101101#,
     16#00011101#,16#10011101#,16#01011101#,16#11011101#,
     16#00111101#,16#10111101#,16#01111101#,16#11111101#,
     16#00000011#,16#10000011#,16#01000011#,16#11000011#,
     16#00100011#,16#10100011#,16#01100011#,16#11100011#,
     16#00010011#,16#10010011#,16#01010011#,16#11010011#,
     16#00110011#,16#10110011#,16#01110011#,16#11110011#,
     16#00001011#,16#10001011#,16#01001011#,16#11001011#,
     16#00101011#,16#10101011#,16#01101011#,16#11101011#,
     16#00011011#,16#10011011#,16#01011011#,16#11011011#,
     16#00111011#,16#10111011#,16#01111011#,16#11111011#,
     16#00000111#,16#10000111#,16#01000111#,16#11000111#,
     16#00100111#,16#10100111#,16#01100111#,16#11100111#,
     16#00010111#,16#10010111#,16#01010111#,16#11010111#,
     16#00110111#,16#10110111#,16#01110111#,16#11110111#,
     16#00001111#,16#10001111#,16#01001111#,16#11001111#,
     16#00101111#,16#10101111#,16#01101111#,16#11101111#,
     16#00011111#,16#10011111#,16#01011111#,16#11011111#,
     16#00111111#,16#10111111#,16#01111111#,16#11111111#);

  function Swap (X : REVERSIBLES) return REVERSIBLES is
  begin
    return (Xlate(X(4)), Xlate(X(3)), Xlate(X(2)), Xlate(X(1)));
  end Swap;

Re: Bit manipulation

[Lutz Donnerhacke]

* Redryder wrote:
>I need to swap the bits in a 32-bit word.

type word32 is 0 .. 2**32-1;

procedure swap32 (i : in word32) returns word32 is
   type  lowrec is record  data : word32;  end record;
   type highrec is record  data : word32;  end record;
   for  lowrec'Bit_Order use Low_Order_First;
   for highrec'Bit_Order use High_Order_First;
   
   function l2h is new Ada.Unchecked_Conversion (lowrec, highrec);
   
   low  :  lowrec := (i);
   high : highrec := l2h(low);
begin
   return high;
end swap32;

It's up to your compiler to find out what's a effictive way to implement this.
Some architectures may use the endianess swap prefix opcode.
\f
Other question: GNAT 3.12p has problems with efficent code of a simple
rotation. How to solve it portable?

with Ada.Unchecked_Conversion;

procedure binary_rotation is
  wordsize : constant := 16;
  
  type word is mod 2**wordsize;
  
  type bitfield is array(1..wordsize) of boolean;
  pragma Pack(bitfield); -- the following clause will not work without pragma
  for bitfield'Size use wordsize;
  
  function w2b is new Ada.Unchecked_Conversion (word, bitfield);
  function b2w is new Ada.Unchecked_Conversion (bitfield, word);
  
  subtype offset is Natural range 1 .. wordsize-1;
  function rotate (b : bitfield; s : offset) return bitfield is
  begin
     return b(b'first .. b'last - s) & b(b'last - s + 1 .. b'last);
  end rotate;
begin
  null;
end binary_rotation;

Re: Bit manipulation

[Robert Dewar]

In article <slrn90vl0k.l5.lutz@taranis.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:

>   pragma Pack(bitfield); -- the following clause will not work
>                          -- without pragma
>   for bitfield'Size use wordsize;

As most certainly you would expect, see RM 13.3:

  53   A Size clause on a composite subtype should not affect
       the internal layout of components.

followed by some gruesome code for doing a rotate, to which
one must ask, why on earth not use the Rotate functions provided
as primitives in Ada 95 (these can be located by looking up
the keyword rotate in the index!)

Yes, I suppose GNAT (or in general any Ada 95 compiler) could
try to optimize this gruesome code, but since no one would
ever write it anyway, why bother?



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Lutz Donnerhacke]

* Robert Dewar wrote:
>  lutz@iks-jena.de (Lutz Donnerhacke) wrote:

>>   pragma Pack(bitfield); -- the following clause will not work
>>                          -- without pragma
>>   for bitfield'Size use wordsize;
>
>As most certainly you would expect, see RM 13.3:
>
>  53   A Size clause on a composite subtype should not affect
>       the internal layout of components.

Thanx. I noticed it some weeks before and missed to remove the comment.

>followed by some gruesome code for doing a rotate, to which one must ask,
>why on earth not use the Rotate functions provided as primitives in Ada 95
>(these can be located by looking up the keyword rotate in the index!)

This piece of code is from my play and experimental grounds. I'd prefer a
portable solution instead of mapping maschine code into a portability lib.
Not all bit manipulation actions provided by the underlying CPU can be
expeced to occur as compiler directives. This becomes especially true, if
some complex manipulations has to be done.

>Yes, I suppose GNAT (or in general any Ada 95 compiler) could try to
>optimize this gruesome code, but since no one would ever write it anyway,
>why bother?

Because the generated code is even worse.

Re: Bit manipulation

[Robert Dewar]

In article <slrn90vsv1.l5.lutz@taranis.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> This piece of code is from my play and experimental grounds.
> I'd prefer a portable solution instead of mapping maschine
> code into a portability lib.

No no no! Rotate_Left is a function defined IN THE ADA 95 RM,
it is a high level function that is defined at the Ada semantic
level. Yes, it will translate to some efficient sequence of
machine instructions (a single rotate instruction, where such
exists, some equivalent clever sequence where it does not).

There is absolutely NO need EVER to do roll-your-own rotates
in Ada 95.

As I say, this is not exactly obscure, if you look up rotate
in the RM index, you will find the reference.

One note here. In the RM, Rotate_Left and Rotate_Right are
defined only on the types in Interfaces, which is a bit
limiting, but for portability across compilers you have to
stick to this.

In GNAT, we permit the definition of an intrinsic (using
pragma Import (Intrinsic,Rotate_xxx)) Rotate_Left/Right for
any user defined modular type, but this is not necessarily
portable (this is actually something the ARG should add as
a recommended enhancement, since it is hard to imagine any
compiler would find it hard to do).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Lutz Donnerhacke]

* Robert Dewar wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) wrote:
>> This piece of code is from my play and experimental grounds.
>> I'd prefer a portable solution instead of mapping maschine
>> code into a portability lib.
>
>No no no! Rotate_Left is a function defined IN THE ADA 95 RM,

Yes. In B.2. I found a obscure definition in the MD5 packet, so I did not
read the RM. My fault. Sorry.

>There is absolutely NO need EVER to do roll-your-own rotates
>in Ada 95.

Rotation was a simple example for my limited mind to play with.

Re: Bit manipulation

[Robert Dewar]

In article <slrn90vl0k.l5.lutz@taranis.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> * Redryder wrote:
> >I need to swap the bits in a 32-bit word.
>
> type word32 is 0 .. 2**32-1;
>
> procedure swap32 (i : in word32) returns word32 is
>    type  lowrec is record  data : word32;  end record;
>    type highrec is record  data : word32;  end record;
>    for  lowrec'Bit_Order use Low_Order_First;
>    for highrec'Bit_Order use High_Order_First;
>
>    function l2h is new Ada.Unchecked_Conversion (lowrec,
highrec);
>
>    low  :  lowrec := (i);
>    high : highrec := l2h(low);
> begin
>    return high;
> end swap32;
>
> It's up to your compiler to find out what's a effictive way to
> implement this.

No, this is completely wrong. Once again, it is *really* a good
idea to actually try out something before posting it here.

Bit_Order confuses many people, since certainly it *sounds*
as though it might do what you expected, but most certainly
it does *not* do anything of the kind.

In fact the solution above is doubly wrong, because the use of
unchecked conversion ensures that nothing actually happens at
all!

You clearly did not compile the code, or you would have seen
other errors as follows:

 1. procedure when you meant function
 2. returns when you meant return
 3. positional aggregate with only one component
 4. wrong return type

All in all, these few lines of code contain a rather high
density of errors, and certainly do not inform this discussion.

It does not take much effort to try out any code you post. I
always do, because even for a simple program, I do not trust
myself to avoid silly mistakes :-)

In any case, read the GNAT documentation to understand what
the real situation here is. The operable sentence from the
GNAT Reference Manual is

  In the case where the non-standard value is specified, the
  effect is to renumber bits within each bit, but the ordering
  of bytes is not affected.

let alone ordering of bits!!!!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Lutz Donnerhacke]

* Robert Dewar wrote:
>  lutz@iks-jena.de (Lutz Donnerhacke) wrote:

>>    for  lowrec'Bit_Order use Low_Order_First;
>>    for highrec'Bit_Order use High_Order_First;
>>
>>    function l2h is new Ada.Unchecked_Conversion (lowrec, highrec);

>No, this is completely wrong. Once again, it is *really* a good
>idea to actually try out something before posting it here.

GNAT can not compile it. Bit_Order can not be set.

>Bit_Order confuses many people, since certainly it *sounds*
>as though it might do what you expected, but most certainly
>it does *not* do anything of the kind.

Very bad. I would offer a perfect way to use the representation clauses for
real world applications. But so they are nearly senseless.

>In fact the solution above is doubly wrong, because the use of unchecked
>conversion ensures that nothing actually happens at all!

Sure? The return statment (with was wrong, because .data was forgotten)
would generate a endianess prefix on reading the memory location. This does
the whole thing. (Using Alpha, Ia64, ...)

>In any case, read the GNAT documentation to understand what the real
>situation here is. The operable sentence from the GNAT Reference Manual is
>
>  In the case where the non-standard value is specified, the
>  effect is to renumber bits within each bit, but the ordering
>  of bytes is not affected.
>
>let alone ordering of bits!!!!

We talk about bit ordering.

Re: Bit manipulation

[Robert Dewar]

In article <slrn90vt78.l5.lutz@taranis.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:


> GNAT can not compile it. Bit_Order can not be set.

That is incorrect, as of version 3.13, GNAT implements
the capability of setting Bit_Order in situations where
this makes sense, including this one.

> >Bit_Order confuses many people, since certainly it *sounds*
> >as though it might do what you expected, but most certainly
> >it does *not* do anything of the kind.
>
> Very bad. I would offer a perfect way to use the
> representation clauses for
> real world applications. But so they are nearly senseless.

Not at all! Setting Bit_Order is quite valuable for some
situations of endian independence. You are just confused
about the purpose and semantics of this capability. The
fact that it does not do what you want it to do does
not make it senseless!

A typical useful application is to specify the position of
bits within a single byte as 8 record componens in a manner
that is endian-independent.

> >In fact the solution above is doubly wrong, because the use
> >of unchecked
> >conversion ensures that nothing actually happens at all!
>
> Sure? The return statment (with was wrong, because .data was
> forgotten)
> would generate a endianess prefix on reading the memory
> location. This does the whole thing. (Using Alpha, Ia64, ...)

Not evan vaguely. Like many people you are confusing byte
endianness with bit order. I would recommend reading the
section in my book on Microprocessors on this subject which
is at least an attempt to sort this out. Note that a lot of
people, including the designers and documenters of the 68K
got confused on this issue.

> >In any case, read the GNAT documentation to understand what
the real
> >situation here is. The operable sentence from the GNAT
Reference Manual is
> >
> >  In the case where the non-standard value is specified, the
> >  effect is to renumber bits within each bit, but the
ordering
> >  of bytes is not affected.
> >
> >let alone ordering of bits!!!!
>
> We talk about bit ordering.


We do indeed! The Bit_Order attribute in Ada talks ONLY about
numbering of the bits, it does NOT provide a facility for
reversing bits AT ALL! So that is why you should read the
documentation carefully. Norman Cohen has also written a useful
piece on Bit_Order, it is in one of the relevant AI's. Perhaps
someone can give the reference.

By the way, we find that helping people through the porting
problems associated with switching endianness is a very common
activity in our support efforts.

One even has to wonder if the original questioner *really* wants
to do what he says he wants to do. In my experience, most people
who want to reverse bits, don't really want to, they are
confused in the same way that Lutz was confused into thinking
that endianness switching involves bit-reversal.

of course there are legitimate requirements for bit order
swaps in the communications area, but you have to wonder ....



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Bit manipulation

[Lutz Donnerhacke]

* Robert Dewar wrote:
>  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
>> GNAT can not compile it. Bit_Order can not be set.
>
>That is incorrect, as of version 3.13, GNAT implements the capability of
>setting Bit_Order in situations where this makes sense, including this
>one.

Great. I found the announcement (it was posted while I was unable to access
any computer)

>Not at all! Setting Bit_Order is quite valuable for some situations of
>endian independence. You are just confused about the purpose and semantics
>of this capability. The fact that it does not do what you want it to do
>does not make it senseless!

>A typical useful application is to specify the position of bits within a
>single byte as 8 record componens in a manner that is endian-independent.

This would ease one of my programming issues. Fine.

>Not evan vaguely. Like many people you are confusing byte endianness with
>bit order.

I see your point. So word8 can only be used:

with Ada.Unchecked_Conversion;
with System;

procedure endian is
  type word8 is mod 2**8;
  type word32 is mod 2**32;
  type composite is array (1..4) of word8;
  pragma Pack(composite);

  type  lowrec is record   val: composite;   end record;
  type highrec is record   val: composite;   end record;
  for  lowrec'Bit_Order use System.Low_Order_First;
  for highrec'Bit_Order use System.High_Order_First;

  function w32tohigh is new Ada.Unchecked_Conversion(word32, highrec);
  function lowtow32  is new Ada.Unchecked_Conversion(lowrec, word32);

  function h2l32 (h : word32) return word32 is
     hr : highrec := w32tohigh (h);
     lr : lowrec;
  begin
     lr.val(1) := hr.val(4);
     lr.val(2) := hr.val(3);
     lr.val(3) := hr.val(2);
     lr.val(4) := hr.val(1);
     return lowtow32 (lr);
  end h2l32;
begin
  null;
end endian;


>I would recommend reading the section in my book on Microprocessors on
>this subject which is at least an attempt to sort this out.

Google did not came back with an URL. May I ask for a hint?

>We do indeed! The Bit_Order attribute in Ada talks ONLY about numbering of
>the bits, it does NOT provide a facility for reversing bits AT ALL!

Yep. I read the passage, but was unable to understand it correctly.

>So that is why you should read the documentation carefully. Norman Cohen
>has also written a useful piece on Bit_Order, it is in one of the relevant
>AI's. Perhaps someone can give the reference.

URL? Google is very quite on this keywords, too.

>One even has to wonder if the original questioner *really* wants to do
>what he says he wants to do. In my experience, most people who want to
>reverse bits, don't really want to, they are confused in the same way that
>Lutz was confused into thinking that endianness switching involves
>bit-reversal.

>of course there are legitimate requirements for bit order swaps in the
>communications area, but you have to wonder ....

Can I use GNAT 3.13 to work with Token Ring MACs ;-)

Re: Bit manipulation

[Pat Rogers]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrn9104p4.l5.lutz@taranis.iks-jena.de...
> * Robert Dewar wrote:
<snip>
> >I would recommend reading the section in my book on Microprocessors
on
> >this subject which is at least an attempt to sort this out.
>
> Google did not came back with an URL. May I ask for a hint?

R. B. K. Dewar and M. Smosna, Microprocessors: A Programmer's View:
McGraw-Hill, 1990.  ISBN for the hardback version is 0-07-016639-0

Still good reading.

---
Patrick Rogers                      Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: Bit manipulation

[Brian Rogoff]

On Mon, 13 Nov 2000, Pat Rogers wrote:
> "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
> > Google did not came back with an URL. May I ask for a hint?
> 
> R. B. K. Dewar and M. Smosna, Microprocessors: A Programmer's View:
> McGraw-Hill, 1990.  ISBN for the hardback version is 0-07-016639-0
> 
> Still good reading.

It's out of print, and isn't even in many libraries, so while it may be a
great book it's a bit unfair to suggest it as a reference. 

I tried to order it about a year or so ago and it was OOP then so this
isn't new news. 

Any chance for a second edition? A web version (like Grune's parsing
textbook), or even class notes? Barring that, how about suggesting a 
reference that people can actually get without incredible effort? :-)

-- Brian

Re: Bit manipulation

[Pat Rogers]

"Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
news:Pine.BSF.4.21.0011131126360.7789-100000@shell5.ba.best.com...
> On Mon, 13 Nov 2000, Pat Rogers wrote:
> > "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
> > > Google did not came back with an URL. May I ask for a hint?
> >
> > R. B. K. Dewar and M. Smosna, Microprocessors: A Programmer's
View:
> > McGraw-Hill, 1990.  ISBN for the hardback version is 0-07-016639-0
> >
> > Still good reading.
>
> It's out of print, and isn't even in many libraries, so while it may
be a
> great book it's a bit unfair to suggest it as a reference.
>
> I tried to order it about a year or so ago and it was OOP then so
this
> isn't new news.
>
> Any chance for a second edition? A web version (like Grune's parsing
> textbook), or even class notes? Barring that, how about suggesting a
> reference that people can actually get without incredible effort?
:-)

I don't quite understand the above.  Are you suggesting I keep track
of whether or not all the books I own are still in print or are
available in libraries?  :-)

He asked for more info so I gave it to him.

Re: Bit manipulation

[F. Britt Snodgrass]

I found and bought my copy last year through http:/www.abebooks.com. 
There is apparently one copy now available at
http://dogbert.abebooks.com/abe/BookDetails?bi=84214139

Britt

Brian Rogoff wrote:
> 
> On Mon, 13 Nov 2000, Pat Rogers wrote:
> > "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
> > > Google did not came back with an URL. May I ask for a hint?
> >
> > R. B. K. Dewar and M. Smosna, Microprocessors: A Programmer's View:
> > McGraw-Hill, 1990.  ISBN for the hardback version is 0-07-016639-0
> >
> > Still good reading.
> 
> It's out of print, and isn't even in many libraries, so while it may be a
> great book it's a bit unfair to suggest it as a reference.
> 
> I tried to order it about a year or so ago and it was OOP then so this
> isn't new news.
> 
> Any chance for a second edition? A web version (like Grune's parsing
> textbook), or even class notes? Barring that, how about suggesting a
> reference that people can actually get without incredible effort? :-)
> 
> -- Brian

Re: Bit manipulation

[Lutz Donnerhacke]

* F. Britt Snodgrass wrote:
>http://dogbert.abebooks.com/abe/BookDetails?bi=84214139

"A book that is now unavailable has been removed from your basket."
Thx anyway.

Re: Bit manipulation

[Georg Bauhaus]

Brian Rogoff (bpr@shell5.ba.best.com) wrote:

: [Dewar/Smosna: Microprocessors]

: Any chance for a second edition?

iirc, Mr. Dewar said "in the making" some months(?) ago, here
in c.l.a.

Re: Bit manipulation

[Lutz Donnerhacke]

* Georg Bauhaus wrote:
>Brian Rogoff (bpr@shell5.ba.best.com) wrote:
>: [Dewar/Smosna: Microprocessors]
>: Any chance for a second edition?
>
>iirc, Mr. Dewar said "in the making" some months(?) ago, here
>in c.l.a.

Great.

Re: Bit manipulation

[Martin Dowie]

er, you realize that the "'Bit_Order" here is unnecessary? try it - it
will make no difference if you comment them out (or make them the
same) as they simply provide a way of referencing bits
(i.e. High_Order_First = bit(0)MSB, Low_Order_First = bit(0)LSB)
and you don't reference any bit positions!

What you have tried to acheive by the use of 'Bit_Order, you have
done by actually doing the assignments. 'Bit_Order played no part.

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message
news:slrn9104p4.l5.lutz@taranis.iks-jena.de...
[snip]
> with Ada.Unchecked_Conversion;
> with System;
>
> procedure endian is
>   type word8 is mod 2**8;
>   type word32 is mod 2**32;
>   type composite is array (1..4) of word8;
>   pragma Pack(composite);
>
>   type  lowrec is record   val: composite;   end record;
>   type highrec is record   val: composite;   end record;
>   for  lowrec'Bit_Order use System.Low_Order_First;
>   for highrec'Bit_Order use System.High_Order_First;
>
>   function w32tohigh is new Ada.Unchecked_Conversion(word32, highrec);
>   function lowtow32  is new Ada.Unchecked_Conversion(lowrec, word32);
>
>   function h2l32 (h : word32) return word32 is
>      hr : highrec := w32tohigh (h);
>      lr : lowrec;
>   begin
>      lr.val(1) := hr.val(4);
>      lr.val(2) := hr.val(3);
>      lr.val(3) := hr.val(2);
>      lr.val(4) := hr.val(1);
>      return lowtow32 (lr);
>   end h2l32;
> begin
>   null;
> end endian;

Re: Bit manipulation

[Lutz Donnerhacke]

* Martin Dowie wrote:
>er, you realize that the "'Bit_Order" here is unnecessary? try it - it
>will make no difference if you comment them out (or make them the
>same) as they simply provide a way of referencing bits
>(i.e. High_Order_First = bit(0)MSB, Low_Order_First = bit(0)LSB)
>and you don't reference any bit positions!

Thanx. I still try to understand that subject.

Re: Bit manipulation

[Randy Brukardt]

Robert Dewar wrote in message <8up1j4$uqe$1@nnrp1.deja.com>...

>We do indeed! The Bit_Order attribute in Ada talks ONLY about
>numbering of the bits, it does NOT provide a facility for
>reversing bits AT ALL! So that is why you should read the
>documentation carefully. Norman Cohen has also written a useful
>piece on Bit_Order, it is in one of the relevant AI's. Perhaps
>someone can give the reference.

The Cohen paper is in AI-133. That version is in plain text; there is a
better PDF version (in which you can see the diagrams - a big help)
available on the ACAA web site in the "grab bag" area. (The ACAA web
site is found at www.ada-auth.org/~acats; I can't check the exact URL of
the Cohen paper since I'm not connected to the net at the moment.

            Randy Brukardt (ARG Editor)

Re: Bit manipulation

[Lutz Donnerhacke]

* Randy Brukardt wrote:
>The Cohen paper is in AI-133. That version is in plain text; there is a
>better PDF version (in which you can see the diagrams - a big help)
>available on the ACAA web site in the "grab bag" area. (The ACAA web
>site is found at www.ada-auth.org/~acats; I can't check the exact URL of
>the Cohen paper since I'm not connected to the net at the moment.

http://www.ada-auth.org/~acats/ai-files/grab_bag/bitorder.pdf
Great ressource. Thank you.

Giving something back to the community (bash scripts to ease development):
\f
function gm {
  DEST="$1"
  if [ -z "$DEST" ]; then
     for DEST in *adb; do
        [ -s $(basename "$DEST" b)s ] || break
     done
  fi
  DEST=$(basename "$DEST" .adb)
  if gnatmake `[-s .gnat_opts] && cat .gnat_opts` "$DEST"; then
     [ -d html/ -a \( ! -s html/index.htm -o "$DEST" -nt html/index.htm \) ] &&
       gnathtml.pl -f -d "$DEST"
  fi
}

function clearall() {
  for i in *.ad[bs]; do
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$i".bak "$j".o "$j".ali "b_$j".c "$j".s ?~"$j".ad[bs]
    fi
  done
  
  for i in *.[hc] *.cpp; do
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$i".bak "$j".o "$j".s
    fi
  done
  
  for i in *.tex; do
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$i".bak "$j".dvi "$j".aux "$j".toc "$j".lo[ftg]
      rm -fv "$j".glo "$j".idx "$j".ilg "$j".ind "$j".ind.aux
    fi
  done
  
  for i in *.mf; do
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$i".bak "$j".dvi "$j".log "$j".[1-9]*gf
    fi
  done
  
  for i in *.web; do
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$j".p "$j".tex
    fi
  done
  
  rm -fv *.txt{~,.bak}
}



-- 
   the \year=2001 TeX calendar; IKS Garamond, 2000; ISBN 3-934601-10-3

Re: Bit manipulation

[Stephen Leake]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> Giving something back to the community (bash scripts to ease development):
> <snip bash scripts>

These scripts may be useful, and they even may be well written. But
since there are no comments, and no other descriptions of what they
are supposed to do, or why I might want to use them, I can't tell!

Bash syntax includes comments; please use them!

-- 
-- Stephe

Re: Bit manipulation

[Lutz Donnerhacke]

* Stephen Leake wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) writes:
>> Giving something back to the community (bash scripts to ease development):
>> <snip bash scripts>
>
>These scripts may be useful, and they even may be well written. But
>since there are no comments, and no other descriptions of what they
>are supposed to do, or why I might want to use them, I can't tell!
>
>Bash syntax includes comments; please use them!

Ok.

function clearall() {    # unlinks all temporary files can be regenerated
  for i in *.ad[bs]; do  # all Ada source files
    if [ -s "$i" ]; then # existing ones
      j="${i%.*}"        # remove extension
      rm -fv "$i"~ "$i".bak "$j".o "$j".ali "b_$j".c "$j".s ?~"$j".ad[bs]
    fi
  done
  
  for i in *.[hc] *.cpp; do  # all C or C++ source files
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$i".bak "$j".o "$j".s
    fi
  done
  
  for i in *.tex; do     # all TeX or LaTeX sources
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$i".bak "$j".dvi "$j".aux "$j".toc "$j".lo[ftg]
      rm -fv "$j".glo "$j".idx "$j".ilg "$j".ind "$j".ind.aux
    fi
  done
  
  for i in *.mf; do      # all METAFONT sources
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$i".bak "$j".dvi "$j".log "$j".[1-9]*gf
    fi
  done
  
  for i in *.web; do     # all Web sources (meta programming/documentation l.)
    if [ -s "$i" ]; then
      j="${i%.*}"
      rm -fv "$i"~ "$j".p "$j".tex
    fi
  done
  
  rm -fv *.txt{~,.bak}   # all editor backups of text files
}
\f
#! /bin/sh

DEST="$1"

if [ -z "$DEST" ]; then   # no argument given => choose best match
  for DEST in *adb; do    # try all files with real work
    [ -s $(basename "$DEST" b)s ] || break # select those w/o  specification
  done
fi

DEST=$(basename "$DEST" .adb) # remove extension

if gnatmake `[ -s .gnat_opts ] && cat .gnat_opts` "$DEST"; then
  # Compiles without errors
  [ -d html/ ] &&  # there is a documentation directory
  [ ! -s html/index.htm -o "$DEST" -nt html/index.htm ] && # remake necessary
    gnathtml.pl -f -d "$DEST"
fi


-- 
   the \year=2001 TeX calendar; IKS Garamond, 2000; ISBN 3-934601-10-3

Re: Bit manipulation

[Sandro Binetti]

In article <2WTH$pdrCfOd@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:

> Quite often when someone wants to do something like that, they had
> formerly programmed in some other language whose ability to define
> data types is not so robust as Ada.

Ok! I'm a C programmer too. Why do you say "robust"? You can write
a "robust" source code even by using other languages than ADA. The
matter is not that. In this case I'd say "flexible", instead of "not
robust".

I always discriminate a data structure in two indipendent points of
wiew:
1) the semantic one (the type, of course)
2) the sintactic one (the way the type is stored and internally
represented)
In some occasion, expecially when you work at low-level device
handling, you need to approach the problem by a semantic (logic) way,
without forgetting that your "idea" has a peculiar way to be treated on
the target hardware (and, so, it can't be completely divided from the
sintactic approach). That's to say that, in such an occasion like
these, there no need (and no meaning) to split the type from its
internal representation: it's only a conceptual overhead!

>
> Except for the particular situation of changing case of an ASCII
> Roman letter (for which Ada95 has built-in capabilities), flipping
> a bit in a character is totally meaningless.

Are you sure? Can you say there'no situation at all in witch you need
to manipulate a seven-bit character, regardless of its ASCII semantic?
Have you ever thougth of some encryption-encoding algorithm, based on
some perverse actions on a character bit?

>
> If you really meant to blip a bit in a data cell that happens to
> be 8 bits wide, then please study record and array declarations
> in an introductory Ada text

Done, when I was 18!

Thanks a lot for your interest in my "stupid" problem.
--
Ciao, Sandro


Sent via Deja.com http://www.deja.com/
Before you buy.

Thank you all for your contribution !

[Sandro Binetti]

Really thanks. :-)

--
Ciao, Sandro


Sent via Deja.com http://www.deja.com/
Before you buy.