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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c5f68ab74d5099ee X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.156.205 with SMTP id y13mr172783bkw.3.1324409724330; Tue, 20 Dec 2011 11:35:24 -0800 (PST) Path: jh9ni34437bkb.0!nntp.google.com!news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Interfaces.Shift_Left Date: Tue, 20 Dec 2011 21:38:00 +0200 Organization: Tidorum Ltd Message-ID: <9lc6bqFfhrU1@mid.individual.net> References: <18214312-82f5-45c4-b20d-cb530b500929@h3g2000yqa.googlegroups.com> <5f989095-5c1c-4b23-a538-d70f4718b4b1@l19g2000yqc.googlegroups.com> <9ktu5mFn31U1@mid.individual.net> <9l71m2FlhuU1@mid.individual.net> Mime-Version: 1.0 X-Trace: individual.net FXnesNEmx07hvfILxLk/NQu3k6QyOEZ9pTvA5Nc9+wV4HTQZMT Cancel-Lock: sha1:TNkSPJbgPUprV/y9Zhm9OkL+R+Q= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2011-12-20T21:38:00+02:00 List-Id: On 11-12-20 02:38 , Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:9l71m2FlhuU1@mid.individual.net... >> On 11-12-16 02:23 , Randy Brukardt wrote: >>> "Niklas Holsti" wrote in message >>> news:9ktu5mFn31U1@mid.individual.net... >>>> On 11-12-15 00:49 , Randy Brukardt wrote: > ... >>>>> Right. This definitely should be done using record representation >>>>> clauses >>>>> if >>>>> there is a choice. >>>> >>>> I'm sorry to say that I disagree, and now always use the shift-and-mask >>>> method. >>> >>> Might as well write in C then, this sort of code is complete, >>> unmaintainable junk. >> >> Ooh, harsh words. I'm trying not to take offence. > > Sorry, that wasn't really aimed at you. Ok. > Your application (which has to > process many foreign machine formats) is highly unusual, and I would not > want most readers to take away the same "lesson" you learned, because it is > wrong in general. I was unclear: I did not mean to claim that one should always avoid record representation clauses, only to say that IMO they are not always the best solution. I should have written a more balanced comment. > But I realize that given the architecture of your system, having a "dirty" > routine doing the conversion into the internal format might very well be the > best solution. The "extract field" function is not very dirty; two shift operations on an unsigned word. And completely portable (as long as Interfaces defines an unsigned type of the required length). > I wouldn't use an "extract field" function in my own code simply because > Janus/Ada does not do inlining of subprograms. Thus the performance hit of > such a function would be severe (it was a factor of 3 for code generation, I > recall.) I haven't measured it, but I don't believe that the "extract field" operation is an important slow-down for me, even if not inlined. The bottle-necks are elsewhere in my app. An "insert field" operation has more overhead than an "extract field" operation. But my application only needs to unpack records with bit-fields, not generate them. > (we didn't have record rep. clauses in the early days of Janus/Ada, > or I surely would have done so). Probably I would have used record representation clauses there, too, since I assume that Janus/Ada was meant to run on and for Intel processors, so there was little cause to fear a change in bit numbering. And of course you know exactly how Bit_Order works in Janus/Ada. Even today, if I were to write an Ada program to run on a particular microcontroller and access the on-chip peripheral control registers, I would use record representation clauses to describe the structure of those registers. The code would probably make many accesses to each record component, making a procedural approach more cumbersome, and there would be no need for portability with regard to bit numbering, since this code would be tied to this microcontroller anyway. > The advantage, of course, is that the instruction description is only in the > text once (as a record type declaration, which is quite readable), rather > than twice (bit extracts in whatever form, plus some documentation of what > they mean). I don't duplicate the record specifications (= the target processor user manual) in my code. The calls of the "extract field" function occur in contexts that give sufficient documentation, IMO. For example, a line like Rd => Register (Word, 15, 12), means that the value of the internal-representation component Rd is taken from bits 15..12 in the input Word. (The name "Rd" is the same as used in the processor user manual for this field, of course. The Register function is a variant of "extract field" that returns the proper type for Rd.) >>>> I used to be charmed by record representation clauses, until I wanted to >>>> write Ada 95 code that was portable between machines with different bit >>>> numbering orders. >>> >>> It's true, that's a problem. Luckily, it's not a real problem in practice >>> for the vast majority of users, since pretty much all popular machines >>> these >>> days use the same bit numbering. >> >> "All the world is a VAX -- no, an Intel -- no, an Xxx", eh? > > Not at all. My understanding is that virtually all recent processors are > little-endian (and all of the new processors in common use). ... > In a sense, this is similar to the 1's complement - 2's complement divide. I get your point. I don't really know, myself, how the trends are going. If big-endian bit-numbering is as rare as 1's complement, you have a good point. > Unless, of course, you are doing processing on/for one of those legacy > systems (which seems to be in part your situation, again, your situation > seems unusual to me). My Ada code was originally written for big-endian SPARC workstations and needed porting to little-endian Intel PCs. I believe the SPARC is still an actively developed architecture. > I view these declarations as a good stand-in for the documentation > (comments) that I'd otherwise have to write. ... > I presume you're not documenting > "the specification" in the code, because otherwise you would have to write > it twice (which would make the record types a lot more attactive). That's right, I just write comments that reference the existing specification doc that defines the record formats, often naming a specific chapter, section, or page. > I wouldn't allow that in my code (I'm not going to make the reader go fumble > with books or PDFs to understand the layout!), but of course YMMV. The mileage varies, indeed: I would consider it downright dangerous to copy the specs (manually) into the code, since this can introduce errors. I don't see any need for a reader to "understand" the layout, since the layout has no impact on meaning. If a reader wants to check that the code uses the right bit numbers and the right interpretation of the fields, it is much better IMO to force the reader to look at the original specs. > [Your extract operation will define the bits involved, but not the > meaning, and I presume how you use the result will help explain the > internal meaning, but not the original definition.] That's right. Each call of an extract operation typically defines the value of a component of the internal representation. The meaning of this component is documented in the type declarations for the internal representation. > Anyway, let me repeat again: YMMV. Your application works for you, and > that's fine. I just don't think that you should tell the world (most of > whose applications are very different from yours) that record represenation > clauses don't work. That was not my intent. The original question was something about "retrieving a 6-bit signed value from a 32-bit field"; you said that record representation clauses "definitely should be used" for this; I wanted to protest against the "definitely", with reasons. I think we understand each other now. > Because they're in the top 5 reasons to use Ada, Is that based on some survey of reasons why Ada is used? That would be interesting. I agree with that ranking only for some Ada applications -- the traditional embedded, bare-machine programs that access hardware registers. Programs that deal with communication protocols may also qualify. And even there, I would not put record representation clauses close to the top of the 5 top reasons. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .