How does Alsys index bit-arrays on Intel ?

How does Alsys index bit-arrays on Intel ?

[Dave Bashford]

Can anyone tell me definitively whether a packed array of bits is indexed
with the least-significant index in the most- or least-significant bit of
each byte on an Intel-targeted Alsys Ada compiler ?

least-significant index in the least-significant bit:
	7,6,5,4,3,2,1,0,15,14,13,12,11,10,9,8,23,22,...
or least-significant index in the most-significant bit:
	0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,...

In other words, will the following program print 32768 or 256 or ?

-----------------------------------------------------------------------------
with text_io; with unchecked_conversion;
procedure tst is
	type Bits is range 0..1;
	type Streams is array( natural range 0..15) of Bits;
	pragma pack( Streams );
	type Word is range 0..65535;
	 for Word'size use 16;
	function Word_Of is new unchecked_conversion( Streams, Word );
	Stream: Streams := Streams'(0 => 1, others => 0);
begin
	text_io.put_line( Word'image(Word_Of(Stream)));
end tst;
-----------------------------------------------------------------------------

thanks,

	p.s. a follow-up and summary of the data-interoperability problem
	I asked about last week is coming. It keeps getting weirder and ...
-- 

db
bashford@srs.loral.com (Dave Bashford, Sunnyvale, CA)

Re: How does Alsys index bit-arrays on Intel ?

[john r strohm]

In article <1993Mar19.193443.524@scf.loral.com> bashford@srs.loral.com (Dave Bashford) writes:
>Can anyone tell me definitively whether a packed array of bits is indexed
>with the least-significant index in the most- or least-significant bit of
>each byte on an Intel-targeted Alsys Ada compiler ?
>
>least-significant index in the least-significant bit:
>	7,6,5,4,3,2,1,0,15,14,13,12,11,10,9,8,23,22,...
>or least-significant index in the most-significant bit:
>	0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,...

This comes up often enough that it is worth saying.

ANSI/MIL-STD-1815A "Reference Manual for the Ada Programming Language"
section 13.4 paragraph 5 contains the following sentence:

  "The ordering of bits in a storage unit is machine-dependent and may
   extend to adjacent storage units."

The same pargraph also contains the following sentence:

  "Whether a component is allowed to overlap a storage boundary, and
   if so, how, is implementation-defined."

In other words, different compilers for different target processors are
allowed to do things differently.

Re: How does Alsys index bit-arrays on Intel ?

[Robert Kitzberger]

john r strohm (strohm@mksol.dseg.ti.com) wrote:
: In article <1993Mar19.193443.524@scf.loral.com> bashford@srs.loral.com (Dave Bashford) writes:
: >Can anyone tell me definitively whether a packed array of bits is indexed
: >with the least-significant index in the most- or least-significant bit of
: >each byte on an Intel-targeted Alsys Ada compiler ?
: >

: This comes up often enough that it is worth saying.
:
: ANSI/MIL-STD-1815A "Reference Manual for the Ada Programming Language"
: section 13.4 paragraph 5 contains the following sentence:
:
:   "The ordering of bits in a storage unit is machine-dependent and may
:    extend to adjacent storage units."
:
: The same pargraph also contains the following sentence:
:
:   "Whether a component is allowed to overlap a storage boundary, and
:    if so, how, is implementation-defined."
:
: In other words, different compilers for different target processors are
: allowed to do things differently.

Sure, but the question is still valid -- quoting the LRM doesn't make the
problem go away.  If I recall, the poster is attempting to transfer 
data between machines in a heterogenous environment.

In order to determine the ordering empirically (the only way I'd trust ;-),
I'd write a test case, and watch what happens on a logic 
analyzer.  If no logic analyzer exists, then write some assembly code
that accepts a bit number and an object, and tests whether that bit
is a zero or a one (this way you can explicitly control the bit ordering).  
Then, create a dummy object and display it's contents as reported by your
assembly routine:

  object := #1234_5678#;
  for I in bits loop
      if assy_bit_is_on( object, I ) then      <---implement in assembly
	  put("1");
      else
	  put("0);
      end if;
  end loop;


As far as the larger problem of normalizing data representations between
dissimiliar architectures, take a look at networking literature for more
ideas (on Unix, "man xdr" for starters).

	.Bob.

--
----------------------------------------------------
Bob Kitzberger		Internet:   rlk@rational.com
Rational		CompuServe: 70743,1550
Grass Valley, CA

Re: How does Alsys index bit-arrays on Intel ?

[Norman H. Cohen]

In article <1993Mar23.023912.1083@rational.com>,
rlk@Rational.COM (Robert Kitzberger) writes: 

|> In order to determine the ordering empirically (the only way I'd trust ;-),
|> I'd write a test case, and watch what happens on a logic
|> analyzer.  If no logic analyzer exists, then write some assembly code
|> that accepts a bit number and an object, and tests whether that bit
|> is a zero or a one (this way you can explicitly control the bit ordering).
|> Then, create a dummy object and display it's contents as reported by your
|> assembly routine: 
|>
|>   object := #1234_5678#;
|>   for I in bits loop
|>       if assy_bit_is_on( object, I ) then      <---implement in assembly
|>        put("1");
|>       else
|>        put("0);
|>       end if;
|>   end loop;

Logic analyzer?  Assembly routine?  A straightforward test can be written
entirely in Ada: 

   with Text_IO; use Text_IO;
   with Unchecked_Conversion;

   procedure Test_Bit_Numbering is

      type Bit is (Zero, One);
      for Bit use (Zero => 0, One => 1);
      for Bit'Size use 1;

      type Bit_Vector is array (Natural range <>) of Bit;
      pragma Pack(Bit_Vector);

      type Word_Type is
         record
            Bit_Zero   : Bit;
            Other_Bits : Bit_Vector(0 .. 30);
         end record;

      for Word_Type use
         record
            Bit_Zero   at 0 range 0 .. 0;
            Other_Bits at 0 range 1 .. Integer'Size-1;
         end record;

      for Word_Type'Size use Integer'Size;

      function Word_To_Integer is
         new Unchecked_Conversion (Word_Type, Integer);

      Word : Word_Type;

   begin

      Word.Bit_Zero := One;
      Word.Other_Bits := (0 .. 30 => Zero);

      if Word_To_Integer(Word) = 1 then
         Put_Line ("Bit zero is the low-order bit.");
      else
         Put_Line ("Bit zero is the high-order bit.");
      end if;

   end Test_Bit_Numbering;

I believe the original question was about numbering the components used
in Boolean arrays rather than about numbering the bits in
record-representation clauses.  It should be obvious how to modify this
program to answer the array-component question too.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: How does Alsys index bit-arrays on Intel ?

[john r strohm]

In article <C4CLou.I5z@watson.ibm.com> ncohen@watson.ibm.com describes an
Ada algorithm to determine which bit (most or least significant) is numbered
how.

The problem is that this tells only how that particular version of that
particular compiler for that particular host and target numbers them.  This
does NOT give any assurance that a compiler from a competing vendor will
do the same thing, nor does it even cover the case of another compiler from
the same vendor, for the same host but a different target, or even (in a
REALLY baroque scenario) for a subsequent release of the SAME compiler.
The language of the standard allows the vendor to do what he/she wishes.

This, in my personal opinion, is one of the few places where Ada goofs.

Now, the flip side is that there is a good argument for making it
implementation-dependent.  Some machines still number bits left-to-right,
while others number right-to-left, and we still have Endian problems
every time we change processors (almost).  Choosing one scheme and
enforcing it is going to cause major heartburn for SOMEBODY, as they
curse the standard because none of their databooks are useable: they
all have the bits numbered backwards.

Re: How does Alsys index bit-arrays on Intel ?

[Dave Bashford]

In article <1993Mar23.202742.26997@mksol.dseg.ti.com> strohm@mksol.dseg.ti.com (john r strohm) writes:
>In article <C4CLou.I5z@watson.ibm.com> ncohen@watson.ibm.com describes an
>Ada algorithm to determine which bit (most or least significant) is numbered
>how.
>
>The problem is that this tells only how that particular version of that
>particular compiler for that particular host and target numbers them.  This
>does NOT give any assurance that a compiler from a competing vendor will
>do the same thing, nor does it even cover the case of another compiler from
>the same vendor, for the same host but a different target, or even (in a
>REALLY baroque scenario) for a subsequent release of the SAME compiler.
>The language of the standard allows the vendor to do what he/she wishes.
>
>This, in my personal opinion, is one of the few places where Ada goofs.
>
>Now, the flip side is that there is a good argument for making it
>implementation-dependent.  Some machines still number bits left-to-right,
>while others number right-to-left, and we still have Endian problems
>every time we change processors (almost).  Choosing one scheme and
>enforcing it is going to cause major heartburn for SOMEBODY, as they
>curse the standard because none of their databooks are useable: they
>all have the bits numbered backwards.
>

Would it be a "major heartburn for SOMEBODY" ? Both Intel and Motorola
number the bits within a byte right-to-left. The 68K intruction set has
a bit-set instruction with right-to-left ordering; to do the same thing
on the Intel requires masking and or'ing. Yet the Ada compiler for the
68K seems to do just fine translating bit numbers. I don't see where it
would be difficult to write a compiler either way - what is a _pain_ is
trying to write portable code in such an environment ! I was under the
apparently mistaken assumtion that portability (platform independence)
was one of the main intentions of the DoD when they decided to create/use
a common language.

This, in my personal opinion, is one of several places where Ada
goofs.  As someone who writes a lot of reusable subsystems, I find all
of the little implementation-dependent features a real pain. A few
things that would help enormously are a standard pre-precessor, a
well-defined alternate-body mechanism, and/or a standard Make tool. I
look with envy at all of the PD stuff on the network that will compile
and run on everything from a DOS to Unix and even VMS, yet I can't
write Ada source that will compile the same on Sun and HP.

P.S.	I hope this doesn't sound like the start of a religious
	argument - I did delete some of the stronger stuff :-) I'm not
	religious just frustrated.  I would like to see a useful thread
	dealing with these issues.
-- 

db
bashford@srs.loral.com (Dave Bashford, Sunnyvale, CA)