From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4e9860765413318c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-24 10:46:08 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!east1.newsfeed.sprint-canada.net!news.storm.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3B8692DE.9000206@home.com> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Hi byte and Lo Byte Question References: <9m0gn6$b6j$1@zeus.orl.lmco.com> <3B843C0C.9A3282B@raytheon.com> <9m34r7$6ka$1@nh.pace.co.uk> <3B860BD6.7A1A8EA3@eraseme.systems.saab.se> <3B867ECA.80502@home.com> <9m61gv$b8s$1@nh.pace.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 24 Aug 2001 17:46:07 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Fri, 24 Aug 2001 11:46:07 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:12391 Date: 2001-08-24T17:46:07+00:00 List-Id: Marin David Condic wrote: > "Warren W. Gay VE3WWG" 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