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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a1ce307c10055549 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-19 05:19:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newsfeed.news2me.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: calenday (was Re: IBM Acquires Rational Ada Date: Thu, 19 Dec 2002 08:18:52 -0500 Organization: MindSpring Enterprises Message-ID: References: <5JfM9.395655$P31.145145@rwcrnsc53> NNTP-Posting-Host: d1.56.b4.ea X-Server-Date: 19 Dec 2002 13:19:26 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:32080 Date: 2002-12-19T13:19:26+00:00 List-Id: Well, there's all kinds of ways of getting what you want. The thing is that you have the rep clause there for this purpose, so you hate to come up with a kludge to get around the fact that it won't. I'll grant that most of the time, it really isn't a problem. The bulk of the time, I don't care about representation at all. When I do care about representation, its typically only as something is going into or coming out of some device and once I've got it picked apart, the data can go into un-represented things where the compiler can do what it likes. Even when we're talking about down at the device level, it usually works because people don't tend to do things that are all that strange. But there are still times when getting the data packed as tight as possible - or dealing with some legacy system - is necessary and you get into issues with the compiler. Tagged records probably present the worst problems if you try to throw representation clauses on them. I've only tinkered with one compiler in this regard, so I can't speak for all of them and I realize that there are special problems in this respect. But if you're going to allow rep clauses on tagged records, there ought to be some ability to actually make them work. Two problems I had were that a) you have no mechanism to find the position/size of the tag, so you have no mechanism to offset everything from it and b) the compiler insisted that all extensions of the record start on a longword boundary and there was no apparent way to tell it to start elsewhere - even though it would have been an even byte or word boundary. It seems to me that those are problems that *could* be addressed and maybe the rep clause would be more useful. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ====================================================================== wrote in message news:5JfM9.395655$P31.145145@rwcrnsc53... > > deal with the data and you discover your compiler is going to whine and > > snivel about being asked to span things across unusual boundaries. > What's wrong with the routine to align things, followed by an > Unchecked_Conversion to something with an acceptable rep spec, approach? > > type Bit_Width_Lists is array(Integer range <>) of Positive; > procedure Align (Source : in Packed_Data; > Control: in Bit_Width_Lists; > Target : out Ada.Streams.Stream_Element_Array); > -- Copy sequential bit strings, inserting padding as needed to ensure > -- that each starts on an alignment boundary in Target. > > Unless only a few of the resultant fields are accessed, this won't be much > slower than having the compiler do the shifting and masking, and if some > fields are accessed a lot, it will actually be faster. This doesn't help > with endianness or foreign floating point etc, but those are semantic > level things that a rep spec can't describe anyway.