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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2d886a1f8c2fd7b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-25 14:09:32 PST Newsgroups: comp.lang.ada Path: sparky!uunet!usc!elroy.jpl.nasa.gov!sdd.hp.com!sgiblab!sgigate!sgi!wdl1!scf16!bashford From: bashford@srs.loral.com (Dave Bashford) Subject: Re: How does Alsys index bit-arrays on Intel ? Message-ID: <1993Mar25.220932.7582@scf.loral.com> Keywords: Ada portability Sender: bashford@scf.loral.com (Dave Bashford) Organization: Loral Space & Range Systems References: <1993Mar23.023912.1083@rational.com> <1993Mar23.202742.26997@mksol.dseg.ti.com> Distribution: inet Date: Thu, 25 Mar 1993 22:09:32 GMT Date: 1993-03-25T22:09:32+00:00 List-Id: In article <1993Mar23.202742.26997@mksol.dseg.ti.com> strohm@mksol.dseg.ti.com (john r strohm) writes: >In article ncohen@watson.ibm.com describes an >Ada algorithm to determine which bit (most or least significant) is numbered >how. > >The problem is that this tells only how that particular version of that >particular compiler for that particular host and target numbers them. This >does NOT give any assurance that a compiler from a competing vendor will >do the same thing, nor does it even cover the case of another compiler from >the same vendor, for the same host but a different target, or even (in a >REALLY baroque scenario) for a subsequent release of the SAME compiler. >The language of the standard allows the vendor to do what he/she wishes. > >This, in my personal opinion, is one of the few places where Ada goofs. > >Now, the flip side is that there is a good argument for making it >implementation-dependent. Some machines still number bits left-to-right, >while others number right-to-left, and we still have Endian problems >every time we change processors (almost). Choosing one scheme and >enforcing it is going to cause major heartburn for SOMEBODY, as they >curse the standard because none of their databooks are useable: they >all have the bits numbered backwards. > Would it be a "major heartburn for SOMEBODY" ? Both Intel and Motorola number the bits within a byte right-to-left. The 68K intruction set has a bit-set instruction with right-to-left ordering; to do the same thing on the Intel requires masking and or'ing. Yet the Ada compiler for the 68K seems to do just fine translating bit numbers. I don't see where it would be difficult to write a compiler either way - what is a _pain_ is trying to write portable code in such an environment ! I was under the apparently mistaken assumtion that portability (platform independence) was one of the main intentions of the DoD when they decided to create/use a common language. This, in my personal opinion, is one of several places where Ada goofs. As someone who writes a lot of reusable subsystems, I find all of the little implementation-dependent features a real pain. A few things that would help enormously are a standard pre-precessor, a well-defined alternate-body mechanism, and/or a standard Make tool. I look with envy at all of the PD stuff on the network that will compile and run on everything from a DOS to Unix and even VMS, yet I can't write Ada source that will compile the same on Sun and HP. P.S. I hope this doesn't sound like the start of a religious argument - I did delete some of the stronger stuff :-) I'm not religious just frustrated. I would like to see a useful thread dealing with these issues. -- db bashford@srs.loral.com (Dave Bashford, Sunnyvale, CA)