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,65f09e2d2d4dad56 X-Google-Attributes: gid103376,public From: Stephen Leake Subject: Re: Representation Clauses And Freezing Date: 2000/07/21 Message-ID: X-Deja-AN: 649179235 References: <3973192E.E7337814@acm.com> <397707E2.CCDB7C44@acm.com> <39784AC3.C2A2B817@acm.com> Content-Type: text/plain; charset=us-ascii X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov X-Trace: skates.gsfc.nasa.gov 964199616 14496 128.183.220.71 (21 Jul 2000 17:13:36 GMT) Organization: NASA Goddard Space Flight Center Mime-Version: 1.0 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 NNTP-Posting-Date: 21 Jul 2000 17:13:36 GMT Newsgroups: comp.lang.ada Date: 2000-07-21T17:13:36+00:00 List-Id: "Marin D. Condic" writes: > Stephen Leake wrote: > > > Making the compiler happy isn't really the issue. If I could accept > > > whatever the compiler insisted on giving me, then I wouldn't need a > > > representation clause, right? > > > > But you can give a rep clause. It's just not the same one as you could > > give if the type were public. So I don't understand what the problem is. > > > Are you serious? What good is a rep clause unless it is the rep clause > that *I* want? If any old rep clause would do, then why bother putting > one on there at all? Decoration? The difference was in the size and alignment representation clauses: You wanted: for Rec_Type use record Field_01 at 4 range 0..15 ; Field_02 at 6 range 0..15 ; Field_03 at 8 range 0..15 ; end record ; for Rec_Type'Size use 10 * System.Storage_Unit; for Rec_Type'Alignment use 4; The compiler will accept: for Rec_Type use record Field_01 at 4 range 0..15 ; Field_02 at 6 range 0..15 ; Field_03 at 8 range 0..15 ; end record ; for Rec_Type'Size use 16 * System.Storage_Unit; for Rec_Type'Alignment use 4; The fields you explicitly located are in the same places. I'm not clear why you can't live with this size and alignment for the record. > Try to imagine that you want to line up a data type to match a hardware > register or a message coming into a system from the outside world. You > have to put a rep clause on the data type so that specific bits, bytes > and words fall into specific positions. Having the compiler reject your > rep clause and suggest another does absolutely no good and is totally > pointless. Clearly the size can't matter, since the only compiler knows the tag size. I can see that alignment might matter, but it should be simple to get the message into the right alignment in the first place. Is that the problem? You also indicate below that you want to specify the locations of additional components in derived types, and that there seems to be padding at the end of Rec_Type above. Instead, assume the extra space is actually additional tag information, and move your fields down: for Rec_Type use record -- tag seems to be 10 bytes Field_01 at 10 range 0..15 ; Field_02 at 12 range 0..15 ; Field_03 at 14 range 0..15 ; end record ; for Rec_Type'Size use 16 * System.Storage_Unit; for Rec_Type'Alignment use 4; Oops, the compiler doesn't like this either; it wants more space. So I don't know what's going on, and I can see that this will not work for derived types; you can't live with "gaps" in the representation. So I am reduced to suggesting that you call ACT, and ask them how to make it work (you are a paying customer?). They may know a work-around, or they may be able to change the compiler to do what you want. > > Yada Yada Yada. Trust me on this - I've done a lot of message passing > stuff and I've always found Ada to be a real nasty bitch (especially 83) > when trying to use it for this kind of application. It is a *lot* easier > to get this out of C or other languages that pretty much let you toss > type safety out the window. (Don't take this as an endorsement of C - > just an illustration.) Perhaps you see it as "easier" in C because C doesn't have tagged types, so none of the issues you are raising here occur. You can always convert a tagged record into an equivalent variant record. Perhaps you cannot afford the run-time overhead to do this, so you are trying to map the tagged record directly onto the byte stream. I agree that is a neat way to do things. > > I think the reason this problem annoys me so much is that over the > years, Ada has taken a lot of heat from real time programmers because it > was viewed as too restrictive. I've defended the language in most cases > because I knew it well enough to know that there was usually some way of > getting what you needed out of it. In the arena of message passing > systems, I've always had to conceed that Ada made you do so many > butt-ugly things to get what you needed done that it almost wasn't worth > it. But you are comparing apples and oranges. C has no tagged types. If you want to say "message passing is easier in C than in Ada", please be sure you are comparing variant records in each, not variant records in C to tagged records in Ada! > Ada95 fixed a lot of sore spots for the real time and embedded > world, but I still can't build the message passing stuff in an > elegant and efficient way - not unless I find a compiler that will > let me get absolute control over the representation of the tagged > types. Either that or give me a "union" and pointers I can translate > into arrays. :-) You have "union" and pointers. Either via Unchecked_Conversion, or via pragma Unchecked_Union. Take the C solution you like, and translate into Ada. Then you'll have the best of both worlds! -- -- Stephe