Re: Help with Copying Shared Memory to Local

["John R. Strohm" <strohm@airmail.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