Bit order in Ada about asn1scc HOT 14 CLOSED

I also experience the same error on PC where the Ada and C code produce different bytes for the same ACN and the same data. See attached code.
asn1cc-bit-order.zip

from asn1scc.

The problem is in the way you dump the bitstream into a file.

If you encode the value 0x0203 then bits should be sent to the other side as follows

0000 0010 0000 0011

This exactly the contents of the bitstream.
Here is a print screen from debugger showing this

To export the contents of the bitstream in a file, I use the following function
`PROCEDURE WRITE_STR_TO_FILE(Strm : adaasn1rtl.BitArray;
DataLen : Natural;
fileName:String) IS
package Seq_IO is new Ada.Sequential_IO(adaasn1rtl.Asn1Byte);
use Seq_IO;

  MASKS : CONSTANT adaasn1rtl.OctetBuffer (1 .. 8) := (16#80#, 16#40#, 16#20#, 16#10#, 16#08#, 16#04#, 16#02#, 16#01#);
  curByte:adaasn1rtl.Asn1Byte:=0;
  bitIndex:Integer;
  My_Out_File : Seq_IO.FILE_TYPE;
BEGIN
  Create(My_Out_File, Out_File, fileName);

  FOR I IN 1..DataLen LOOP
     bitIndex := ((I-1) mod 8) +1;
     IF bitIndex = 1 THEN
        curByte:=0;
     END IF;
     IF Strm(I)=1 THEN
       curByte := curByte OR MASKS(bitIndex);
     END IF;
     IF bitIndex = 8 OR I = DataLen THEN
        Write(My_Out_File, curByte);
     END IF;
  END LOOP;

  Close(My_Out_File);
END;    

`
Using this function, the contents will be written the way you expect.

from asn1scc.

Thank you for looking into my problem. Does this mean that a memory buffer that was encoded with the C library cannot be directly decoded by the Ada library and vica versa? And do I need to reverse the bits of incoming IMU messages (at 200 Hz) if I want to decode with Ada?

from asn1scc.

You have to use the function I provided in order to properly dump the Ada BitArray into a byte buffer. By dosin so, you can encode/decode messages between C and Ada and even in different processor architectures (arm with intel etc).
The runtime libraries of C and Ada were developed at different times using a different strategy. The C RTL has a byte stream and is much easier to dump it to a file. Ada uses a BitArray which at the time of writing was considered to be a more clear and more understandable way to deal with bits encoding.

from asn1scc.

Just to rephrase it and make sure the original concern is clearly addressed: the ACN encoding should be identical between C and Ada and there should not be any need to reverse the bits to decode it in Ada if encoded in C. If that's not the case, it is a bug that needs to be fixed.

from asn1scc.

OK, after some further tests it seems indeed that there is an issue with one of the two runtimes. We have to investigate further and provide a solution to this issue.

from asn1scc.

Thank you, this is what I would expect. If I encode a datagram with the C library I should be able to decode it with the SPARK version without altering the bits first. As stated in my initial comment, the problem seems to be the usage of packed bit-arrays in Ada, and that your expected bit-order is not the one produced by GNAT that sees index 0 as the least significant of the byte. I would recommend to alter the SPARK library to work on byte-arrays (perhaps even from the standard package System.Storage_Elements) and follow the pattern as in the C library. I tested the encoding the message above one million times, and the C library is 16 times faster than Ada with the same compiler optimizations, so there also seems to be a significant performance hit on using bits instead of bytes. I am willing to contribute on this work.

from asn1scc.

@gmamais :Can this we worked in isolation, i.e. only by updating the RTL (adaasn1rtl.ad?) and perhaps the string template outputs for Spark backend, or would this imply changes in the code of the compiler?

from asn1scc.

Yes, the changes can be implemented in isolation (files C:\prj\GitHub\asn1scc\SPARK_RTL\adaasn1rtl.adb and C:\prj\GitHub\asn1scc\SPARK_RTL\adaasn1rtl.ads) .

The Ada functions that must be modified are only the ones that actually read or write directly in the BitArray. These functions are:
BitStream_AppendBit, BitStream_ReadBit, BitStream_AppendByte, BitStream_DecodeByte
BitStream_AppendPartialByte, BitStream_ReadNibble, BitStream_Encode_Non_Negative_Integer
BitStream_Decode_Non_Negative_Integer, Acn_Enc_Boolean_true_pattern, Acn_Dec_Boolean_true_pattern, Acn_Enc_Boolean_false_pattern, Acn_Dec_Boolean_false_pattern
Acn_Enc_NullType_pattern, Acn_Dec_NullType_pattern, Acn_Enc_NullType_pattern2,
Acn_Dec_NullType_pattern2

Moreover the definition of the BitArray must change from
type BitArray is array (Natural range <>) of BIT;
to
type BitArray is array (Natural range <>) of Asn1Byte;

if the changes to these specific functions are restricted only inside their body (and not in their interface) then no modification is required in the code of the ASN.1 compiler.

from asn1scc.

Thanks. Before optimizing the Ada runtime, perhaps we should first establish clearly who is currently right between C and Ada about the bit ordering. The uPER standard should be the reference - since we also need to check interoperability with other ASN.1 tools. Have you checked already?

from asn1scc.

By the way, Kristoffer, make sure you are on the latest version, which is currently the branch named ASN1SCC_V4. It has major modifications compared to the master (more than one year of work) - complete tool refactoring, dozen of bug fixes and new features, mostly on ACN side.

from asn1scc.

The bit order of C is definitely right. In the past, we used to compare the generate bitstream against another compiler at the bit level and the encoded buffer was written to the file as is without any bit reordering. On the other hand, for the Ada comparison against the other ASN.1 compiler, we had first to invoke the WRITE_STR_TO_FILE procedure which internally changes the order of the bits in each byte.

from asn1scc.

The issue has been fixed in the master branch, now Ada and C encodings are fully aligned.

from asn1scc.

Issue has been fixed. Ada and C encodings are fully aligned.

from asn1scc.