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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 18 Jul 93 21:07:02 GMT From: mcsun!news.funet.fi!funic!news.eunet.fi!prime!mits!rkaivola@uunet.uu.net (Risto Kaivola) Subject: Record representation on MC680X0 Message-ID: List-Id: 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)