Re: Help with Copying Shared Memory to Local

["John Cupak" <Jcupak744@attbi.com>]

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" <strohm@airmail.net> 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" <jrcarter@acm.org> 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
>
>