Re: Hi byte and Lo Byte Question

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Marin David Condic wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
> news:3B867ECA.80502@home.com...
> 
>>I see where you're going on the "efficiency" argument, but ignoring that
>>for a moment, what about a different approach..
>>
>>Someone could craft an Ada subset (declaration) language, that is
>>compiled by a small compiler (like a CORBA IDL compiler), and
>>generates a resulting package body and spec, in existing Ada95
>>terms to accomplish what you want.
>>
>>A better way might be to use ASIS with the necessary "code" added to
>>generate your packages (some commercial venture has probably already
>>done this at some point).
> 
> I'd really hate to have to be running some sort of preprocessor just to get
> automatic creation of all the Unchecked_Conversions I might want. This would
> be more painful than simply creating the Unchecked_Conversion or declaring
> an overlay of a Stream_Element_Array on top of all the types I might want to
> convert.


I wasn't suggesting a pre-processor, although the "tool" could be used
that way. I was just suggesting a tool that took Ada declarations, and
did the grunt work for you (a one-shot deal).  After that, you have the
option of processing any changes again, or maintaining it by hand.
I admit, this is not an elegant solution ;-)


> You aren't really extending the language per se. You're just adding another
> type/object attribute, so syntactically it remains the same. I believe
> implementations might have some latitude to create attributes like this and
> not be in violation of the standard, so it could be an extension without a
> language update.
> 
>>Of course, the draw back to this approach is that you don't avoid the
>>data copying that would be required by the generated code. The advantage
>>however, would be to keep the language from growing in size. If you
>>look at:
>>
>> >>for X in My_Type'Raw_Data (My_Data)'Range loop
>> >>    Some_Storage_Element := My_Type'Raw_Data (My_Data) (X) ;
>> >>end loop ;
>>
>>there is some data copying on a Some_Storage_Element basis anyway.
> 
> But no motion of My_Data to some intermediate structure just to be able to
> treat it as bytes. The Some_Storage_Element part was just there to
> demonstrate something syntactically correct. The important part is the
> My_Type'Raw_Data (My_Data) (X) part. You can reference all the bytes of
> My_Data without having to do:


Yes, I understand your point.


> Another_Block_Of_Data := My_Unchecked_Conversion (My_Data) ;

...

> 
>>Unless Ada0Y were to gain endian representation features, I think
>>a certain amount of copying (internal or external) would be
>>necessary anyway. But I have to admit, that a representation
>>clause for endianess would be extremely convenient. Then at least
>>the compiler can do it in the most effective manner for the
>>platform it was compiled on.
>>
> 
> What's wrong with ARM 13.5.3 Bit Ordering and using "for X'Bit_Order use
> High_Order_First ;" and similar (Low_Order_First )? I'm pretty sure that
> should work and do what you want - never needed to mess with it myself -
> yet. (Day ain't over, yet!)


I had forgotten about that (and not used it yet).  But I was under
the impression that it only affects the numbering of the bits -- not
the actual implementation of the "word". I'll have to review it again.

However, there are endian situations that cannot be described by
"for'Bit_Order". Thankfully they are rare on modern architectures.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg