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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d2cba5965c7bfcd5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-06 03:53:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!feed2.news.rcn.net!rcn!chnws02.ne.ipsvc.net!cyclone.ne.ipsvc.net!24.128.8.70!typhoon.ne.ipsvc.net.POSTED!not-for-mail From: "Jeffrey Creem" Newsgroups: comp.lang.ada References: <3C823A1A.6030006@users.sf.net> <0CFB5EECF8614F8D.52C8F36A468D2F14.3AD3D533D2B72FDB@lp.airnews.net> <01D3EF1F744692CE.E4285A1E194C94B7.800ACE8F1D3EC3C7@lp.airnews.net> <482822EEF13389AC.7CF0F33D21F3D96D.C977F409C9057456@lp.airnews.net> Subject: Re: 64bit access to an array of 8bit values X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Wed, 06 Mar 2002 11:50:03 GMT NNTP-Posting-Host: 66.31.5.146 X-Complaints-To: abuse@mediaone.net X-Trace: typhoon.ne.ipsvc.net 1015415403 66.31.5.146 (Wed, 06 Mar 2002 06:50:03 EST) NNTP-Posting-Date: Wed, 06 Mar 2002 06:50:03 EST Organization: ATT Broadband Xref: archiver1.google.com comp.lang.ada:20856 Date: 2002-03-06T11:50:03+00:00 List-Id: "John R. Strohm" wrote in message news:482822EEF13389AC.7CF0F33D21F3D96D.C977F409C9057456@lp.airnews.net... > Well, that is precisely what I did. After explaining why the pointer > hacking he wanted to do did not work in the EXTREME GENERAL case, I showed > several alternatives that all WOULD work in the EXTREME GENERAL case. Sorry..Upon re-reading I see you did give the correct alternative "The first easy answer is that you model your memory as an array of Bit64, and do the necessary bitpicking to extract the Bit8, Bit16, and Bit32 values yourself. If your machine doesn't support Bit64-like objects, then do it as Bit32 and hack around the Bit64 access. The other easy answer is that you model your memory as an array of Bit8, and then you build up your Bit16, Bit32, and Bit64 accesses by doing multiple Bit8 fetches and stores." (Note that the statement "The Ada compiler is not required to allocate precisely one byte per array element, and it probably didn't." is still incomplete since it fails to discuess various rep spec issues). In fairness the rep spec issues are mostly irrelevant with the solution you propose.. However, my initial concern still stands (and this is not just true here but I've seen similar discussions crop up on the C++ and other mailing lists)... The problem with the way the response is phrased is people walk away with the understanding that they can not use the simple straightforward approach in Ada so they have to resort to something more complicated. In fact, the problems you point out are common to all languages (with the possible exception of Java which always runs with the same endianness regardless of host but then of course would probably now allow the evil pointer arithmetic that seemed to be desired so perhaps in that case the answer really could have been you can't do it like that in XX lang). > > The object of programming in a high-order language is that you DO *NOT* WANT > to deal with the idiosyncrasies of the target machine's architecture. To a > first approximation, 99.9% of the code in a serious embedded system is > totally, utterly, completely INDEPENDENT of the target architecture. The > other 0.1% (say 1000 lines out of a million LOC system) is heavily > target-dependent, and has to cope with it all. For that 0.1%, Ada provides > machine code insertions, and every implementation I have seen provided a > capability for interfacing to assembly language code ("pragma linkage", as I > recall: it has been several years since I last dealt with Ada and assembly > language interface). (Yes, I have done Ada machine code insertions, on a TI > 320C40. It was NOT fun. We had a very tight limit on the amount of real, > live assembly language we could write, but machine code insertions didn't > count against the limit, so...) > > Close to thirty years ago, one of the Big Names in computer science had an > article in "Software Practice and Experience". I think it was Nicklaus > Wirth. They had just ported their PASCAL compiler to a PDP-11, and were > testing something that had to do with character strings. They set up what > they THOUGHT should have printed as "ABCD", and were quite disconcerted when > it printed "BADC". They asked, in the article, for enlightenment as to what > had gone wrong. THEY WERE MYSTIFIED. This was in the early days, when the > problems created by the little-endianness of the PDP-11 were still eating > everyone alive. (In fact, the terms "endian-ness", "little-endian", and > "big-endian" were not yet in common use in computing.) The catch is that > they had written code that implicitly assumed big-endianness, because every > machine they'd ever encountered was big-endian. (If memory serves me, the > PDP-11 was the very first little-endian architecture.) > > The underlying problem with what the original poster wanted to do was this: > the endian-ness of his emulated machine MAY OR MAY NOT have matched the > endian-ness of his target hardware. With a pointer-coercing scheme, you > explicitly accept whatever endian-ness the target hardware imposes on you. > This is not necessarily good: consider what happens, FOR EXAMPLE, when you > try to model a (big-endian) 68020 on a (little-endian) Pentium. It gets > even worse if you have a process with a mode bit that SWITCHES endian-ness > on the fly for you. > > Running a pointer-coercing scheme also runs the risk, as someone else > pointed out, of encountering SIGBUS traps, if the emulated machine allows > unaligned multibyte transfers but the target hardware (running the emulator) > doesn't. Try simulating a 68040 (which allows unaligned transfers) on a > 68000 (which doesn't). > > "Jeffrey Creem" wrote in message > news:YSch8.50282$%b6.13414165@typhoon.ne.ipsvc.net... > > > > > What this taught me is that solutions that work "most of the time" DON'T > > > work ALL of the time, and the right answer is never be satisfied with > > > something that doesn't work ALL of the time. Correctness is a binary > > > property. > > > > > > I don't entirely disagree but when face with an answer like "Sorry you > can't > > do that [in Ada]" a > > person asking such a question will go off and say well I better do that in > C > > then when in reality all of the > > problems you bring up would exist there as well....Your answer was not "No > > do it this way instead" but > > rather "You can't do that". I suspect following that advice I could > convince > > myself that I can not write any software > > so perhaps I should be a gardener. (After all, Hello World will not work > on > > an embedded machine with no display so it is clearly not possible to write > > Hello World in Ada) > > > > > > > >