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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b77305e4038ca5a X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Representation Clause Bit Ordering Date: 1999/07/09 Message-ID: <3786718D.A7618C1C@hso.link.com>#1/1 X-Deja-AN: 499264738 Content-Transfer-Encoding: 7bit References: <37860BA1.CF7E58B2@averstar.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Training Inc. Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-07-09T00:00:00+00:00 List-Id: Tucker Taft wrote: > > Jeff Susanj wrote: > > > > We are trying to define records for an external device that is defined in > > fractional binary with 16 bit storage units (the leftmost bit is bit 0 and > > the rightmost bit is 15) and our processor is an integer binary machine with > > 32 bit storage units (the leftmost bit is bit 32 and the rightmost bit is > > 0). I believe there must be some way in Ada to define this and still be > > portable. > > The Bit_Order attribute is not designed for "flipping" > bits or bytes. It simply changes the numbering of bits > in a record rep clause. > > > ... We have tried using the 'Bit_Order attribute but with the > > High_Order_First our Green Hills compiler generates 32 bit data which seems > > consistant with the LRM but doesn't work for our application. Does anyone > > have any ideas? > > If you need to flip bits or bytes, you will need to do that yourself > manually. You can minimize mistakes by making the flipped-bit type > private, with operations for fetching/storing "normal" values into it. > > > Jeff Susanj > > -- > -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ > Technical Director, Distributed IT Solutions (www.averstar.com/tools) > AverStar (formerly Intermetrics, Inc.) Burlington, MA USA Two anecdotes along these lines. A group has a hardware device to which they need to interface. This pretty straigh-forward stuff since the device is memory mapped to a fixed location. A record-rep clause and an address clause (Ada 83) works nicely. Then comes along a software emulation of the device produced by a third-party contractor. The problem is the memory map used by the emulator is different from the actual device. How they got by with that I haven't a clue. In come some folks to my desk wringing hands and bemoaning the situation and wondering how they can pass emulator stuff to the hardware and vice versa without a lot of memory mangling. I point out that derived types can have individual rep-clauses. I suggest they define a parent type with no rep-clause and two derived types, one for the hardware and one for the software. Each of the derived type then has the appropriate rep-clause. A simple type conversion on assignment between the two kinds of objects and the Ada compiler will handle all the memory mangling automagically. Problem solved. I only mention the above because some months later the same group come to me with another problem. This time the same memory-mapped device is visible to two different architectures. Each architecture they are writing code for uses different compilers. Each compiler uses a different bit-ordering on the rep-clauses. Lets call them compiler X and compiler Y. They took all that into account and used my derived type approach. Then they wondered by the type conversion failed to produce the desired results. Of course, by simply pointing out that the rep-clause for compiler Y was not appropriate for Compiler X, and vice versa, and that no type conversion is necessary since this situation did not involve different memory maps, they quickly saw the error of their ways. I then suggested that this is more a variant code issue and that having both representations around would involved process safeguards to insure the wrong types were not used. Simpler to have one type (since their is one device and one memory layout) and leave it to the configuration management system to insure the correct variant of the code is available. I suppose the new Ada 95 Bit_Order attribute will help in this situation if/when we migrate from Ada 83. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!"