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,98e311935a219163 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-24 08:11:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.airnews.net!cabal11.airnews.net!cabal1.airnews.net!news-f.iadfw.net!usenet From: "John R. Strohm" Newsgroups: comp.lang.ada Subject: Re: Help with Copying Shared Memory to Local Date: Fri, 24 May 2002 10:05:39 -0700 Organization: Airnews.net! at Internet America Message-ID: <478AE9B914ED6844.5DEC7C5E64D6473E.909AD32BDF37CFA7@lp.airnews.net> X-Orig-Message-ID: References: <3CED51CF.39E26FC6@acm.org> <3CEDA095.61BE6EF6@acm.org> Abuse-Reports-To: abuse at airmail.net to report improper postings NNTP-Proxy-Relay: library2.airnews.net NNTP-Posting-Time: Fri May 24 10:11:10 2002 NNTP-Posting-Host: !^=CF1k-WArk(cj (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:24652 Date: 2002-05-24T10:05:39-07:00 List-Id: Jeffrey, I surmise that you have not spent a lot of time doing device drivers in embedded systems. Modern microprocessors typically support memory accesses for bytes, words (doublebytes) and longs (quadbytes), under (assembly language) programmer control. Electrical engineers designing peripheral devices for embedded ROUTINELY build devices that only respond to one width of access. Serial ports frequently respond only to byte accesses, because that's what the chip deals with. (It is usually impossible to get a serial port chip to respond "correctly" to a 16-bit access, because the chip is only physically capable of reading or writing one 8-bit register at a time.) MIL-STD-1553B interfaces routinely respond only to 16-bit accesses, because MIL-STD-1553B is inherently a 16-bit subsystem. In the world of embedded system peripherals, it is actually quite rare to find an I/O device that responds uniformly (and correctly) to all widths of access. Device driver programmers learn, typically very early in their careers, that they MUST be able to control the kind of access generated, so that they will be able to access the device correctly. This kind of control has historically been tricky at best in languages other than Ada. I remember a Microsoft C 7.0 project in which it was flatly impossible: the hardware required 16-bit accesses, and Microsoft's C compiler "knew" which byte it wanted and DEMANDED to be allowed to generate an 8-bit access. Ada representation specifications provide a clean way to tell the compiler what kind of access to use, and most compilers were good about following the programmer's wishes. "Jeffrey Carter" wrote in message news:3CEDA095.61BE6EF6@acm.org... > Randy Brukardt wrote: > > > > Humm, I wouldn't expect that code to have the proper memory read/write > > (16-bits) that you specified. And in any case, even if it works, nothing > > would require that staying correct. > > I assumed that Storage_Unit was 16, since the hardware doesn't support > byte access. Of course, I may have made a donkey out of someone and his > brother in so doing. > > If needed, one can declare an Atomic mod 2 ** 16 type, and associated > unconstrained array type with Atomic_Components, and hopefully guarantee > the required behavior. If not, one can always guarantee appropriate > object code by using a machine code insertion. > > -- > Jeff Carter > "We call your door-opening request a silly thing." > Monty Python & the Holy Grail