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.2 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, XPRIO_SHORT_SUBJ autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,78b2880bc7e78e39 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-19 08:46:16 PST Path: supernews.google.com!sn-xit-03!supernews.com!freenix!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: RISC Date: Mon, 19 Mar 2001 11:34:38 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <995cfh$mm9$1@nh.pace.co.uk> References: <98qumf$5sf$1@nh.pace.co.uk> <98r4g1$7r1$1@nh.pace.co.uk> <3AB22CB2.E8A851A5@averstar.com><98tmai$5q5$1@nh.pace.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 985019697 23241 136.170.200.133 (19 Mar 2001 16:34:57 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 19 Mar 2001 16:34:57 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: supernews.google.com comp.lang.ada:5851 Date: 2001-03-19T16:34:57+00:00 List-Id: Werll, not being a compiler kind of guy, I don't really know what the problems are. I think I understand what you're getting at - that the reading and writing of individual fields can cause all sorts of problems for efficient compilation. Hence my notion of restricting usage isn't really going to help. I suppose it is worth pointing out that in the *bulk* of the cases, a rep clause isn't going to ask for things that are going to be hard or inefficient. You use the rep clause to give yourself a nice, warm, fuzzy feeling that somehow that 32 bit, longword aligned integer is going to *always* fall in this position within the record so you're not scared that a new compiler version is going to go move it on you and your I/O with some other device is now screwed up. (I've had *SERIOUS* troubles with compilers when asking for very simple things, like putting various record fields on 16 bit boundaries for a machine that supports 16 bit data. But Noooooooo! Data had to fall on 32 bit boundaries or the compiler puked.) In the cases where we have to deal with the perversities of some hardware engineer who never worked on a compiler or had to build software to deal with his strange representation of data, I guess I'd be willing to live with inefficient code so long as I had some means of plugging in the data in and impacting the device properly. If someone stuck an odd sized integer(1) into some location that spanned longword boundaries and I've somehow got to plug a number in there, I'd rather have an inefficient way of doing it than getting told by the compiler that it won't do that at all because it is a dumb idea - or simply get confused and think I was asking for a representation that can't be done. (1) I once had a serious disput with a casino roulette wheel operator over what I considered to be an "odd" number. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" wrote in message news:wccbsr1qw7b.fsf@world.std.com... > The complexity that Tucker was talking about is in generating code for > reading and writing components. If you want any reasonable kind of > efficiency, and you insist on generality, the compiler needs to know > several ways of accessing components: those that are nicely aligned on > storage unit boundaries, those that are bit fields within a single word, > those that are bit fields crossing word boundaries, those that are bit > fields that are bigger than a word, &c. And it's machine dependent > (some machines have double-word shifts and whatnot), which means the > complexity is multiplied across all targets supported. >