Endian-problem/bug with system.bit_ops (gnat3.15)...

Endian-problem/bug with system.bit_ops (gnat3.15)...

[Erik Baigar]

Dear Ada users,

in porting an application from Meridian's Ada83 to gnat3.15 I
encountered
some issues with the system.bit_ops. They (especially the Bit_And which 
I used) show behaviour which depends on the processor used:

The code contains expressions of the form
 
  Bit_And ( MEMORY (OPERAND_ADDRESS)'Address,18, ACCUMULATOR'Address,18,
            ACCUMULATOR'Address);

which are used in the simulation of a vintage processor. I used length
18 here since the processor has 18-bit registers. This code works well
on the Intel (little endian) platform but fails on SPARC (big endian).
It required some investigation to locate the problem, but replacing 
the length 18 by 32 (all are integers here), i.e. using

  Bit_And ( MEMORY (OPERAND_ADDRESS)'Address,32, ACCUMULATOR'Address,32,
            ACCUMULATOR'Address);

solved the problem and the code now runs on little and big endian 
systems. I know, system.bit_ops are version dependent and non portable,
but I'd not expect behaviour depending on the target system at the 
first glance... 

   Regards,

      Erik.

Re: Endian-problem/bug with system.bit_ops (gnat3.15)...

[Niklas Holsti]

Erik Baigar wrote:
> Dear Ada users,
> 
> in porting an application from Meridian's Ada83 to gnat3.15 I
> encountered some issues with the system.bit_ops...
>  
>   Bit_And ( MEMORY (OPERAND_ADDRESS)'Address,18, ACCUMULATOR'Address,18,
>             ACCUMULATOR'Address);
> 
> ... This code works well
> on the Intel (little endian) platform but fails on SPARC (big endian).
> It required some investigation to locate the problem, but replacing 
> the length 18 by 32 (all are integers here), i.e. using
> 
>   Bit_And ( MEMORY (OPERAND_ADDRESS)'Address,32, ACCUMULATOR'Address,32,
>             ACCUMULATOR'Address);
> 
> solved the problem and the code now runs on little and big endian 
> systems.

Anything that accesses a variable using Variable'Address but then 
operates only on a part of the variable (eg. 18 bits of a 32-bit 
variable) sounds very likely to have problems with endianness, if 
the storage unit is smaller than the size of the variable.

Did you have a question to ask, or did you just want to report this 
problem and your solution?

I think that your program could be made more portable by avoiding 
'Address (and, of course, System.Bit_Ops) and using instead modular 
types (not available in Ada83) and their predefined bitwise "and" 
and "or" operations.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Endian-problem/bug with system.bit_ops (gnat3.15)...

[Erik Baigar]

Niklas Holsti wrote:
> Did you have a question to ask, or did you just want to report this
> problem and your solution?
Since the problem is solved by including all 32bits the posting is 
not really a question - maybe the posting will give someone else, 
encountering the same problem, a hint what to look out for...

> I think that your program could be made more portable by avoiding
> 'Address (and, of course, System.Bit_Ops) and using instead modular
> types (not available in Ada83) and their predefined bitwise "and"
> and "or" operations.
Do you have an estimation on performance? The current code 
is quite fast in emulating the vintage processor (more than 
3.5MIPS in the simulation) using the non portable System.Bit_Ops...

   Thanks and best regards,

       Erik.

Re: Endian-problem/bug with system.bit_ops (gnat3.15)...

[Niklas Holsti]

Erik Baigar wrote:
> Niklas Holsti wrote:
> 
>>Did you have a question to ask, or did you just want to report this
>>problem and your solution?
> 
> Since the problem is solved by including all 32bits the posting is 
> not really a question - maybe the posting will give someone else, 
> encountering the same problem, a hint what to look out for...

Ok, good. (I meant no criticism, I just wondered if, or how, I 
could help.)

>>I think that your program could be made more portable by avoiding
>>'Address (and, of course, System.Bit_Ops) and using instead modular
>>types (not available in Ada83) and their predefined bitwise "and"
>>and "or" operations.
> 
> Do you have an estimation on performance? The current code 
> is quite fast in emulating the vintage processor (more than 
> 3.5MIPS in the simulation) using the non portable System.Bit_Ops...

As I understand it, and have observed in some programs and some 
targets, a bitwise operation (and, or, xor, not) on modular types 
with a power-of-two modulus translates directly into the 
corresponding machine instruction. I expect such modular types to 
be as fast as System.Bit_Ops, even if the operations in 
System.Bit_Ops are intrinsic or inlined.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Endian-problem/bug with system.bit_ops (gnat3.15)...

[Erik Baigar]

Niklas Holsti wrote:
> As I understand it, and have observed in some programs and some
> targets, a bitwise operation (and, or, xor, not) on modular types
> with a power-of-two modulus translates directly into the
> corresponding machine instruction. I expect such modular types to
> be as fast as System.Bit_Ops, even if the operations in
> System.Bit_Ops are intrinsic or inlined.

Thanks for this information... Hopefully I will find the time
to give this one a try,

    best regards,

      Erik.