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-05 22:07:20 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!supernews.com!news.airnews.net!cabal10.airnews.net!cabal1.airnews.net!news-f.iadfw.net!usenet From: "John R. Strohm" Newsgroups: comp.lang.ada Subject: Re: 64bit access to an array of 8bit values Date: Tue, 5 Mar 2002 23:30:48 -0800 Organization: Airnews.net! at Internet America Message-ID: <482822EEF13389AC.7CF0F33D21F3D96D.C977F409C9057456@lp.airnews.net> X-Orig-Message-ID: References: <3C823A1A.6030006@users.sf.net> <0CFB5EECF8614F8D.52C8F36A468D2F14.3AD3D533D2B72FDB@lp.airnews.net> <01D3EF1F744692CE.E4285A1E194C94B7.800ACE8F1D3EC3C7@lp.airnews.net> Abuse-Reports-To: abuse at airmail.net to report improper postings NNTP-Proxy-Relay: library1-aux.airnews.net NNTP-Posting-Time: Tue Mar 5 23:44:19 2002 NNTP-Posting-Host: !\q/01k-W0n]3Hj (Encoded at Airnews!) 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: archiver1.google.com comp.lang.ada:20844 Date: 2002-03-05T23:30:48-08:00 List-Id: 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. 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) > > >