Re: Representation clauses for base-64 encoding

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:9m0433FjokU1@mid.individual.net...
> On 11-12-23 03:42 , Randy Brukardt wrote:
>> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
>> news:9lgls6FticU1@mid.individual.net...
>> ...
>>>> http://www.adacore.com/2008/03/03/gem-27/
>>>
>>> I am surprised and disappointed that there is *no* mention of 
>>> portability
>>> problems in that "gem". This is marketing hype for GNAT, not sound
>>> programming advice.
>>
>> There is no portability problem in common use.
>
> Depends on what you consider common. The gem even claims that its 
> representation clause makes "Ada" use a biased 7-bit representation for an 
> Integer component with range 100..227. RM chapter 13 only recommends that 
> compilers should support unbiased representations.
>
> Which Ada compilers, other than GNAT, can use biased representations?

Ah, I missed that. I don't know of any other Ada compilers that support 
biased representations.

...
> Natasha's 24-bit-record code works only if the Ada implementation (a) 
> supports chapter 13 as recommended and (b) has a machine scalar of at 
> least 24 bits.

No, not true. Machine scalars only come into play if you need to use the 
non-native bit order, and that isn't needed here.

Once you have to work with the non-native bit order, things get messy. But 
that is rarely needed.

> We know that some Ada programs run on the 16-bit TI MSP430. Will the 
> 24-bit record code work there? Ok, MSP430 Ada programs are uncommon, but 
> perhaps we want to make them more common.

Sure, it will work there, so long as you don't try to mess with the 
non-native bit order.

> Natasha's code that uses (packed) arrays with Component_Sizes of 6 and 8 
> bits has more complex portability questions. Of course it also requires 
> support for chapter 13, but I think it needs more than that. It depends on 
> the indexing order and the word size. I don't find anything in chapter 13 
> or elsewhere in the RM that even requires the indexing order to be the 
> same for different array types, although this is of course very likely to 
> be the case.

Worrying about indexing order is just plain silly. As Bob points out, 
*nothing* is really required by a standard, you have to trust implementers 
to do reasonable things.

>> The problem occurs when you need to process big-endian data on a
>> little-endian machine (or vice versa). That is not that common of a 
>> need --
>
> The problem occurs when an application inputs or outputs binary data, and 
> the application should be coded in a portable way. I can't believe that 
> this is uncommon.

Only if the binary data is in the non-native bit order. If the binary data 
is in the native bit order, there is nothing that special that needs to be 
done. And it doesn't matter which bit order that is.

>> Most code does not care which bits are which bits in the word -- like 
>> this
>> encoding code -- they just need a consistent representation. That is, it
>> doesn't matter where bit 0 is, so long as it is the same in every item 
>> that
>> is processed.
>
> True for internal data, false for inputs and outputs.

Not really. The vast majority of inputs and outputs are in text form (as in 
the encoding example). Most of the rest are just a pure stream of bytes. And 
the interesting thing with a stream of bytes is that you get identical 
behavior for both bit orders -- because the bit order and byte order are 
tied together. The problem comes when you try to use the non-native bit and 
byte order on a machine.

For instance, in the encoding example, all of the messy manipulation occurs 
completely inside the application: the input is a stream of bytes and the 
output is a stream of characters -- neither are subject to any byte order 
issues themselves. That being the case, which bytes go where (internally) 
turns out to be irrelevant, because the native order will have the right 
effect either way.

It took me a long time to grasp this; I only figured it out after struggling 
for a long time with our old 68000 code generator (which is big-endian, of 
course). Once I got the code selection right, nothing much needed to be 
changed. I understand when others don't see this; it's easy to think too 
much in terms of the exact bits involved, but those matter less than it may 
seem.

                                                                 Randy.