Record representation on MC680X0

Record representation on MC680X0

[Risto Kaivola]

  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.
  As you probably know, these processors store the most significant
byte of an integer value first, so that if the 16-bit value 16#1234#
is stored at the address 0, it looks like

address ->      0        1 
byte value-> 16#12#   16#34#

The bit numbering for normal purposes would be as follows:

address                 ->|            0         |              1         |
                                                 |
byte bit number         -> 7  6  5  4  3  2  1  0|  7  6  5  4  3  2  1  0

16-bit word bit number  -> 15 14 13 12 11 10 9  8|  7  6  5  4  3  2  1  0

bit value               -> 0  0  0  1  0  0  1  0|  0  0  1  1  0  1  0  0


On the other hand, Motorola also define a 'bit-field' bit numbering, which
is as follows (for the same value):

address                 ->             0         |              1

byte bit number (bit f.)-> 0  1  2  3  4  5  6  7|  0  1  2  3  4  5  6  7

16-bit word bit # (b.f.)-> 0  1  2  3  4  5  6  7|  8  9  10 11 12 13 14 15

bit value               -> 0  0  0  1  0  0  1  0|  0  0  1  1  0  1  0  0


Now, at first sight, the first numbering scheme might seem more natural
for implementations targeting Motorola-based systems.  But I think it is
somewhat problematic, or at least confusing for components whose size is
greater than 8 bits.
  I would like to know which numbering scheme your favourite
implementation uses (by default, if more than scheme is available through
pragmas).

--
Risto Kaivola
(Internet address:   rkaivola@mits.mdata.fi)

Re: Record representation on MC680X0

[cis.ohio-state.edu!news.sei.cmu.edu!ae]

rkaivola@mits.mdata.fi (Risto Kaivola) asks about bit-numbering
interpretation in record representation clauses.

Meridian Ada for the Macintosh numbers the right-most bit, the least
significant bit, as zero.

Tartan, Inc. has compilers targetted to bare 680x0 platforms but I do
not know how they handle this question.  Their point of contact is
Susan Englert at 412-856-3600, or send e_mail to
	Englert@Tartan.Com

I'm sure other vendors support the 680x0; I don't know who they are.

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu

Re: Record representation on MC680X0

[magnesium.club.cc.cmu.edu!news.sei.cmu.edu!ae]

rkaivola@mits.mdata.fi (Risto Kaivola) asked about bit numbering by Ada
compilers targetted to Motorola's 680x0 chips.

I answered earlier about Meridian Ada on the Mac.  I've since learned
that Tartan's 68xxx compilers also number bits right-to-left, the least
significant bit being numbered 0.

I also understand that Tartan now supports the 68020, 68030, 68040,
68332 and 68340 targets switch-selectably in one compiler--an offering
that is unique in the market.

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu

Re: Record representation on MC680X0

[agate!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!news.umbc.edu!]

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