* Re: Representation Clause Bit Ordering [not found] <FEI5r9.Iy7@news.boeing.com> @ 1999-07-09 0:00 ` Tucker Taft 1999-07-09 0:00 ` Samuel T. Harris 1999-09-08 0:00 ` Joe Wisniewski 0 siblings, 2 replies; 5+ messages in thread From: Tucker Taft @ 1999-07-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Representation Clause Bit Ordering 1999-07-09 0:00 ` Representation Clause Bit Ordering Tucker Taft @ 1999-07-09 0:00 ` Samuel T. Harris 1999-09-08 0:00 ` Joe Wisniewski 1 sibling, 0 replies; 5+ messages in thread From: Samuel T. Harris @ 1999-07-09 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Representation Clause Bit Ordering 1999-07-09 0:00 ` Representation Clause Bit Ordering Tucker Taft 1999-07-09 0:00 ` Samuel T. Harris @ 1999-09-08 0:00 ` Joe Wisniewski 1999-09-08 0:00 ` Peter Hermann 1 sibling, 1 reply; 5+ messages in thread From: Joe Wisniewski @ 1999-09-08 0:00 UTC (permalink / raw) OK, those of good long-term memories.... was it in Ada Letters about 4-5 years ago, there was a paper written about something very close to this issue; or an endian-ness independent approach for rep-specs, or something like this??????? Joe Tucker Taft wrote in message <37860BA1.CF7E58B2@averstar.com>... >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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Representation Clause Bit Ordering 1999-09-08 0:00 ` Joe Wisniewski @ 1999-09-08 0:00 ` Peter Hermann 1999-09-08 0:00 ` Pat Rogers 0 siblings, 1 reply; 5+ messages in thread From: Peter Hermann @ 1999-09-08 0:00 UTC (permalink / raw) Joe Wisniewski <wisniew@acm.org> wrote: > OK, those of good long-term memories.... was it in Ada Letters about > 4-5 years ago, there was a paper written about something very close > to this issue; or an endian-ness independent approach for rep-specs, > or something like this??????? I dug out the following: --snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip From: "Norman H. Cohen" <ncohen@watson.ibm.com> Newsgroups: comp.lang.ada Subject: Re: Rep Specs,endian,ncohen Date: Thu, 10 Oct 1996 12:02:05 -0400 Organization: IBM Thomas J. Watson Research Center Lines: 83 Message-ID: <325D1DFD.3DE1@watson.ibm.com> References: <3259589E.1740@smtp.svl.trw.com> <325A510D.14E1@gsfc.nasa.gov> <53g3ag$1otk@info4.rus.uni-stuttgart.de> Reply-To: ncohen@watson.ibm.com NNTP-Posting-Host: socks1.watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (Win95; I) Peter Hermann wrote: > I remember Norman H. Cohen has written an essay about the endian > /portability problem somewhere in AdaLetters(?). "Endian-Independent Record Representation Clauses", Ada Letters XIV, No. 1 (January/February 1994), pp. 27-29 Stephen Leake's solution appears to be an instance of the approach suggested in the article. The article gives the general recipe for constructing the component clauses. Note that the problem being solved here is the porting of the source text for record-representation clauses, NOT the run-time translation of a byte stream from one endianness to another. Please disregard the assertion in the article that this problem would be solved in Ada 9X by an attribute definition clause for the 'Bit_Order attribute. The implementation advice in RM95-13.5.3(8) allows a compiler to reject an attribute-definition clause for the nondefault bit order in all the useful cases. Compilers are generally allowed to reject nondefault 'Bit_Order definitions because the designers of Ada 95 believed that component clauses interpreted according to the nondefault bit order could specify noncontiguous bit fields, an implementation nightmare. However, that depends on how you interpret the meaning of a bit offset in a nondefault-endian component clause. If you insist that at B range 10 .. 12 be synonymous, assuming 8-bit bytes, with at B+1 range 2 .. 4 then you do indeed get noncontiguous bit fields. But another interpretation is to look at the highest bit number, say b, specified with a given byte offset, and to view all component clauses with that byte offset as specifying a contiguous range of bits within the smallest "loadable storage unit" (byte, halfword, word, or doubleword on a typical 32-bit or 64-bit machine) having at least b+1 bits. For example, given the component clauses A at 0 range 0 .. 5; B at 0 range 6 .. 11; C at 0 range 12 .. 15; and no other "at 0" component clauses, we would assume that A, B, and C reside within a 16-bit loadable storage unit at offset 0, and that when this 16-bit field is loaded into a register, B is a contiguous field of bits somewhere in the middle of this 16-bit unit. Whether A is at the high-order end or the low-order end of the 16-bit unit depends on which bit ordering applies to the record type, but either way, there is a sensible interpretation with B specifying a field that is contiguous when loaded. Given this interpretation of bit offsets, there is a one-to-one correspondence between record representation clauses that specify a given layout when interpreted as big-endian clauses and other record representation clauses that specify the "same" layout when interpreted as little-endian representation clauses. (I explain below what I mean when I say that layouts are the "same".) Thus it would be practical to require all compilers to support nondefault-endian record-representation clauses, with an attribute-definition clause for T'Bit_Order determining how the record-representation clause for type T is to be interpreted. This would solve the source portability problem by allowing the programmer to arbitrarily specify a layout in his favorite bit order, knowing that a compiler that is big-endian by default and a compiler that is little-endian by default will interpret the record-representation clause the "same" way. When I say that a layout on a big-endian machine and a layout on a little-endian machine are the "same", I mean that the layout is divided into "loadable storage units" with the same sizes and byte offsets, and that the left-to-right bit position of each record component within corresponding loadable storage units is the same. These are the only properties of a layout that can be usefully preserved among opposite-endian machines. -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Representation Clause Bit Ordering 1999-09-08 0:00 ` Peter Hermann @ 1999-09-08 0:00 ` Pat Rogers 0 siblings, 0 replies; 5+ messages in thread From: Pat Rogers @ 1999-09-08 0:00 UTC (permalink / raw) I have simple package supporting this approach for Ada 95 at http://www.classwide.com/products/freecode.htm Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote in message news:7r5861$gob$1@infosun2.rus.uni-stuttgart.de... > Joe Wisniewski <wisniew@acm.org> wrote: > > OK, those of good long-term memories.... was it in Ada Letters about > > 4-5 years ago, there was a paper written about something very close > > to this issue; or an endian-ness independent approach for rep-specs, > > or something like this??????? > > I dug out the following: > > --snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip > > From: "Norman H. Cohen" <ncohen@watson.ibm.com> > Newsgroups: comp.lang.ada > Subject: Re: Rep Specs,endian,ncohen > Date: Thu, 10 Oct 1996 12:02:05 -0400 > Organization: IBM Thomas J. Watson Research Center > Lines: 83 > Message-ID: <325D1DFD.3DE1@watson.ibm.com> > References: <3259589E.1740@smtp.svl.trw.com> <325A510D.14E1@gsfc.nasa.gov> <53g3ag$1otk@info4.rus.uni-stuttgart.de> > Reply-To: ncohen@watson.ibm.com > NNTP-Posting-Host: socks1.watson.ibm.com > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > X-Mailer: Mozilla 3.0 (Win95; I) > > Peter Hermann wrote: > > > I remember Norman H. Cohen has written an essay about the endian > > /portability problem somewhere in AdaLetters(?). > > "Endian-Independent Record Representation Clauses", Ada Letters XIV, No. > 1 (January/February 1994), pp. 27-29 > > Stephen Leake's solution appears to be an instance of the approach > suggested in the article. The article gives the general recipe for > constructing the component clauses. > > Note that the problem being solved here is the porting of the source > text for record-representation clauses, NOT the run-time translation of > a byte stream from one endianness to another. > > Please disregard the assertion in the article that this problem would be > solved in Ada 9X by an attribute definition clause for the 'Bit_Order > attribute. The implementation advice in RM95-13.5.3(8) allows a > compiler to reject an attribute-definition clause for the nondefault bit > order in all the useful cases. > > Compilers are generally allowed to reject nondefault 'Bit_Order > definitions because the designers of Ada 95 believed that component > clauses interpreted according to the nondefault bit order could specify > noncontiguous bit fields, an implementation nightmare. However, that > depends on how you interpret the meaning of a bit offset in a > nondefault-endian component clause. If you insist that > > at B range 10 .. 12 > > be synonymous, assuming 8-bit bytes, with > > at B+1 range 2 .. 4 > > then you do indeed get noncontiguous bit fields. But another > interpretation is to look at the highest bit number, say b, specified > with a given byte offset, and to view all component clauses with that > byte offset as specifying a contiguous range of bits within the > smallest "loadable storage unit" (byte, halfword, word, or doubleword > on a typical 32-bit or 64-bit machine) having at least b+1 bits. For > example, given the component clauses > > A at 0 range 0 .. 5; > B at 0 range 6 .. 11; > C at 0 range 12 .. 15; > > and no other "at 0" component clauses, we would assume that A, B, and C > reside within a 16-bit loadable storage unit at offset 0, and that when > this 16-bit field is loaded into a register, B is a contiguous field of > bits somewhere in the middle of this 16-bit unit. Whether A is at the > high-order end or the low-order end of the 16-bit unit depends on which > bit ordering applies to the record type, but either way, there is a > sensible interpretation with B specifying a field that is contiguous > when loaded. > > Given this interpretation of bit offsets, there is a one-to-one > correspondence between record representation clauses that specify a > given layout when interpreted as big-endian clauses and other record > representation clauses that specify the "same" layout when interpreted > as little-endian representation clauses. (I explain below what I mean > when I say that layouts are the "same".) Thus it would be practical to > require all compilers to support nondefault-endian record-representation > clauses, with an attribute-definition clause for T'Bit_Order determining > how the record-representation clause for type T is to be interpreted. > This would solve the source portability problem by allowing the > programmer to arbitrarily specify a layout in his favorite bit order, > knowing that a compiler that is big-endian by default and a compiler > that is little-endian by default will interpret the > record-representation clause the "same" way. > > When I say that a layout on a big-endian machine and a layout on a > little-endian machine are the "same", I mean that the layout is divided > into "loadable storage units" with the same sizes and byte offsets, and > that the left-to-right bit position of each record component within > corresponding loadable storage units is the same. These are the only > properties of a layout that can be usefully preserved among > opposite-endian machines. > > -- > Norman H. Cohen > mailto:ncohen@watson.ibm.com > http://www.research.ibm.com/people/n/ncohen > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-09-08 0:00 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <FEI5r9.Iy7@news.boeing.com> 1999-07-09 0:00 ` Representation Clause Bit Ordering Tucker Taft 1999-07-09 0:00 ` Samuel T. Harris 1999-09-08 0:00 ` Joe Wisniewski 1999-09-08 0:00 ` Peter Hermann 1999-09-08 0:00 ` Pat Rogers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox