Re: Record representation on MC680X0

[agate!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!news.umbc.edu! nobody@ucbvax.Berkeley.EDU (Mike Berman)]

(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.