From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 21 Jul 93 18:58:48 GMT From: agate!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!news.umbc.edu! nobody@ucbvax.Berkeley.EDU (Mike Berman) Subject: Re: Record representation on MC680X0 Message-ID: <22k3l8INNp0u@umbc4.umbc.edu> List-Id: (Risto Kaivola) writes: > I'm interested in the approach to record representation clauses that >Ada vendors for systems based on Motorola's MC680x0 line have taken, >especially for the 68020 and higher. Specifically, I'm interested in >the convention used in numbering the bits in component clauses. All 680x0 based projects using Ada (that I'm familiar with) have hit this same problem. The best way I've heard the problem summarized is that, while Ada record representation clauses require bit and storage unit numbering to start at 0, nowhere is it defined what 0 means. Therefore, there is built-in flexibility for implementing bit representations. Most implementations pick an ordering that results in bit and storage unit numbering increasing in the same direction. This is not how Motorola numbers their bits, however. The compilers that I've seen for the 680x0 uniformly take the approach you show in your second example. This makes it easier and more straightforward to define record field layouts which cross storage unit boundaries. Oddly, when I first ran into this same situation, I looked through the 68020 user's guide to see what the Motorola bit numbering standard was. Nowhere did I find it stated that bit numbering was the way it was - the 'standard' scheme is derived only from its use in pictures and examples. Now, I know that the user's guide is not akin to the LRM, but I equate this with the logic I sometimes hear that the one, true capitalization standard is defined by the standard chosen for the examples in the LRM (it isn't, by the way). >-- >Risto Kaivola >(Internet address: rkaivola@mits.mdata.fi) -- Mike Berman University of Maryland, Baltimore County Fastrak Training, Inc. berman@umbc.edu (301)924-0050 The views represented in the above post are my own.