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-25 17:59:54 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newsfeed-west.nntpserver.com!hub1.meganetnews.com!nntpserver.com!203.109.225.2!nntp-relay.ihug.net!ihug.co.nz!news.stealth.net!news.stealth.net!news-east.rr.com!chnws02.ne.ipsvc.net!cyclone.ne.ipsvc.net!24.128.8.70!typhoon.ne.ipsvc.net.POSTED!not-for-mail From: "John Cupak" Newsgroups: comp.lang.ada References: <3CED51CF.39E26FC6@acm.org> <3CEDA095.61BE6EF6@acm.org> <478AE9B914ED6844.5DEC7C5E64D6473E.909AD32BDF37CFA7@lp.airnews.net> Subject: Re: Help with Copying Shared Memory to Local X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Sun, 26 May 2002 00:55:41 GMT NNTP-Posting-Host: 66.31.64.136 X-Complaints-To: abuse@attbi.com X-Trace: typhoon.ne.ipsvc.net 1022374541 66.31.64.136 (Sat, 25 May 2002 20:55:41 EDT) NNTP-Posting-Date: Sat, 25 May 2002 20:55:41 EDT Organization: ATT Broadband Xref: archiver1.google.com comp.lang.ada:24811 Date: 2002-05-26T00:55:41+00:00 List-Id: Jeffry, et al, As this is Memorial Day weekend, and I'm not at work, I can't ask the person who brought this problem to my attention just what processor they're using. But, I suspect that this is a very restricted embedded processor/system and that the timing/chip/etc problem is VERY applicable to the solution here. When I get into work on Tuesday, I'll ask for hardware details - something I (a poor software engineer) forgot to do when presented with the problem. John "John R. Strohm" wrote in message news:478AE9B914ED6844.5DEC7C5E64D6473E.909AD32BDF37CFA7@lp.airnews.net... > 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 > >