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,df854b5838c3e14 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Gripe about Ada, rep specs that won't. Date: 1996/03/26 Message-ID: #1/1 X-Deja-AN: 144356377 references: <00001a73+00002504@msn.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-03-26T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >But if 7 bits are required to generate a 'Size of 7, which is reasonable, >then the same requirement would require a record with 1023 booleans >to have a 'Size of 1023, which is NOT reasonable, since large objects >like this are reaonably rounded to a storage unit boundary. But the paragraph we're arguing about has an explicit exception for things that are bigger than a "word". The implementation defines what "word" means, but it's intended to match what the hardware can do -- i.e. if you have 32-bit registers, and you can add, multiply, subtract, and divide 32-bit integers in a single instruction, then clearly a word ought to be 32 bits. So there's no requirement that 1023 booleans be packed into 1023 bits -- the implementation can round up to 1024, because that's a multiple of the word size. >In Ada 83, the programmer had control in the 7 bit case by explicitly >setting the size to 7. This is absolutely standard coding practice in >most large applications we see, the programmer is definitely interested >in the value of the size. True, although in my experience, many Size clauses are pretty confused -- the Ada 83 RM is confused about what it means, the ARG ruled on it (and I doubt if the average programmer read those rulings), and now we find that RM95 didn't get it right, either. >However, the Ada 95 RM does not, as we have discussed, require any rep >clauses for 'Size of records to be accepted. True, I and I agree it should have. >P.S. It is always worth a disclaimer that this discussion is still largely >theoretical. GNAT and most other Ada 95 compilers will fully implement >the rep clauses that are needed. I would define this set as > > Those that are simply mapped to the hardware One could argue about exactly what that means. RM95-13 is attempt to define this concept more precisely, and we see that we forgot some things. The ARG can rule on those points. But I still think that's the right approach -- otherwise, you end up with implementers deciding that "simply mapped to the hardware" means "we don't have to implement chap 13 at all", as in the early days of Ada 83. Or else you end up with the ARG legislating all kinds of fancy stuff that people don't really need, as in the later days of Ada 83. Legislation by the courts makes me uneasy. > + > > Those that are widely used in existing code > > + > > Those that soeone is willing to pay for You keep stating this disclaimer, and I keep agreeing with it, but we continue to argue about it. Methinks we both just like to argue, instead of doing our jobs. ;-) The above sets are pretty much overlapping. I mean, people who design low-level data formats, for the most part make them fairly efficient on the machine(s) they're interested in, and efficient more-or-less means "simply mapped to the hardware", so most of the things one needs to interface to are in all of the above sets. There are exceptions. E.g. the segment tables on the 386 are weird, primarily for upward compatibility with earlier processors (you have to fit the bits in where you can). And once in a while you run across some weird device that hands you a stream of 9-bit values, and you want to deal with it as an array. - Bob