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,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-20 10:12:12 PST From: "Martin Dowie" Newsgroups: comp.lang.ada References: <98qumf$5sf$1@nh.pace.co.uk> <98r4g1$7r1$1@nh.pace.co.uk> <3ab1d090$1@pull.gecm.com> <98t8la$rc$1@nh.pace.co.uk> <3ab72c8f$1@pull.gecm.com> <997pq4$i35$1@nh.pace.co.uk> Subject: Re: RISC Date: Tue, 20 Mar 2001 18:09:59 -0000 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 NNTP-Posting-Host: sg2c11210.dsge.edinbr.gmav.gecm.com Message-ID: <3ab79ade$1@pull.gecm.com> X-Trace: 20 Mar 2001 18:01:02 GMT, sg2c11210.dsge.edinbr.gmav.gecm.com Path: supernews.google.com!sn-xit-03!supernews.com!hermes2.visi.com!news-out.visi.com!xfer10.netnews.com!netnews.com!opentransit.net!news.tele.dk!194.42.224.136!diablo.netcom.net.uk!netcom.net.uk!easynet-monga!easynet-melon!easynet.net!btnet-feed5!btnet!newreader.ukcore.bt.net!pull.gecm.com!sg2c11210.dsge.edinbr.gmav.gecm.com Xref: supernews.google.com comp.lang.ada:5909 Date: 2001-03-20T18:09:59+00:00 List-Id: > Do you mean unchecked conversion? That works, but it forces you to move the > data twice just to satisfy language rules & may be too inefficient for some > apps. Its not A Bad Thing in my estimation, but I'd rather not have to. No, I really meant checked conversions. We have a whole suite of generics that take in enumerations and constant arrays of integers (different subprograms for different sizes) and provide x<->y conversions. For arrays of packed booleans we have subprograms that take in 8/16/32 booleans and do the modulo arithmatic. Not exactly efficient, but they seem to be highly portable. We also provide a endian_convert a parameter (defaulted to false). Most of our data does fall on natural word boundaries anyway (just not all of them) so the really inefficient routines are hardly ever used. In most systems the i/o is a fairly trivial percentage of the %cpu-time and if we need to make any optimisations then there is usually a better candidate after a bit of analysis. > Well, that's fine for everything used internal to the system. The moment > data enters/leaves the system from/to some other source, you *really* want > to guarantee the representation is what is expected. How would you do this > without representation clauses? As above :-) > You'd have to check with a language lawyer. My impression is that this is > what the attribute is for. Go ahead and declare a stream of bytes for the > I/O part to work. Once you get the data, you reference an overlaid record to > pull the data apart. I think the 'Valid attribute should force a check of > the data "assigned" to the record. (Probably works with Unchecked_Conversion > as well...) Of course, you just do all this stuff backwards to handle > output. Any lawyers out there? > I don't think overlays were ever not "guaranteed to work" in Ada83 - at > least no more or less so than in Ada95. (You may have cases where the > compiler or linker pukes on you. I've had this happen attempting to overlay > things from different contexts.) They were/are considered to be "A Bad > Thing" because of the inherent lack of safety involved. (Much like the use > of gotos is frowned upon, but they are still supported.) It is recognized > that overlays can provide an elegant and effective solution to a number of > problems (such as this one!) if they are used carefully and judiciously. The > language attempts to discourage their use because programmers will, like > most normal people, abuse the privilege if left unrestrained. RM83, 13.5.something "Address clauses should not be used to achieve overlays of objects or overlays of program units. Nor should a given interrupt be linked to more than one entry. Any program using address clauses to achieve such effects is erroneous." But I've yet to find anything as explicit about this in RM95 :-( > I think the ARM probably says something about programs relying on overlays > being "erroneous" or some other carefully defined term that basically means > "it may work but all bets are off from a language lawyer's perspective." > This is probably because there is no good universal way of defining behavior > across all hardware and compiler implementations. > > So go ahead and use overlays, but realize you're operating without a net. I may start toying with overlays if this 'Valid thang works... cheers.