Help with Copying Shared Memory to Local

Help with Copying Shared Memory to Local

[John Cupak]

A colleague asked me to help him solve an memory copy problem.

The source memory location is in a "shared" area, and the
destination memory location is "local" to the application.

The original code, written in Ada83, works by copying two bytes
at a time. Evidently, the hardware crashes if they try to access
a single byte.

Here's the Ada 95 version of the original Ada83 code:

-- Assumed visibility of Project_Types
procedure Copy_Double_Byte(Destination : in System.Address;
                           Source      : in System.Address;
                           Length      : in Natural) is
   
  Destination_Pointer : Project_Types.Double_Byte_Pointer;
  Source_Pointer      : Project_Types.Double_Byte_Pointer;
   
begin -- Copy_Double_Byte
   
  -- Ensure source address in correct range
  if Source >= System.Addresses.Logical_Address(Project_Types.Virtual_Base_Address)
and
  Source < System.Addresses.Logical_Address(Project_Types.Virtual_Base_Address
+ 16#200_000#) then
      
     -- Must reference memory on double byte boundry
     -- The number of bytes to copy is specified by the Length
parameter
     for Index in 0..(Length/2) - 1 loop
         
        -- Create source and destination pointers from base address
plus double byte offsets
        Destination_Pointer := Project_Types.To_Double_Byte_Pointer(
                                
System.Deprecated.Incr_Addr(Destination, Index * 2));
        Source_Pointer      := Project_Types.To_Double_Byte_Pointer(
                                 System.Deprecated.Incr_Addr(Source,  
   Index * 2));
         
        -- Copy contents
        Destination_Pointer.all := Source_Pointer.all;
         
     end loop;
      
  end if; -- Source check
   
end Copy_Double_Byte;

I found a 1997 reference in this newsgroup (comp.lang.ada) to a
similar problem entitled
"Q: How to do memory access with gnat" from Michael Erdman
(boavista@berlin.snafu.de)
with references to the Ada95 System.Address_To_Access_Conversions
child package and
the System.Storage_Elements child package.

So, before I go off and write up a new version of the "memory copy"
procedure using
these two child packages, has anyone ever implemented such a solution
that would be
willing to share?

Comments and recommendations always appreciated.

John Cupak

Re: Help with Copying Shared Memory to Local

[Jeffrey Carter]

John Cupak wrote:
> 
> A colleague asked me to help him solve an memory copy problem.
> 
> The source memory location is in a "shared" area, and the
> destination memory location is "local" to the application.
> 
> The original code, written in Ada83, works by copying two bytes
> at a time. Evidently, the hardware crashes if they try to access
> a single byte.
> 
> Here's the Ada 95 version of the original Ada83 code:
> 
> -- Assumed visibility of Project_Types
> procedure Copy_Double_Byte(Destination : in System.Address;
>                            Source      : in System.Address;
>                            Length      : in Natural) is

There's about a 9 out of 10 chance that this system does not need to be
dealing with addresses; that this way of doing things was dreamed up by
a C person who lacked the necessary familiarity with Ada 83 to be
competent to create this specification. I have seen this kind of misuse
of the language far too many times for it to be likely that this case is
different.

You rarely need to use addresses in Ada; this particular example almost
certainly did not need to use addresses even in Ada 83. Maybe you're
stuck with it, in which case you can probably do

Storage_Length : constant Storage_Count :=
   Storage_Count ( (8 * Length + Storage_Unit - 1) / Storage_Unit);
-- Convert Length (in 8-bit bytes) to work with Storage_Elements

A : Storage_Array (1 .. Storage_Length);
for A'Address use Destination;
pragma Import (Ada, A);

B : Storage_Array (1 .. Storage_Length);
for B'Address use Source;
pragma Import (Ada, B);

...

A := B;

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail

Re: Help with Copying Shared Memory to Local

[John Cupak]

Jeffrey,

What a refreshing solution!

I don't know why they're using pointers or addresses, either. Probably, as
you noted, a C-hacker
trying to write Ada.

I've forwarded your suggested solution to the maintenance programmer who
brought the problem
to my attention. Let's see if it flys.

Thanks again - Occam's razor strikes again!

John
"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3CED51CF.39E26FC6@acm.org...
> John Cupak wrote:
> >
> > A colleague asked me to help him solve an memory copy problem.
> >
> > The source memory location is in a "shared" area, and the
> > destination memory location is "local" to the application.
> >
> > The original code, written in Ada83, works by copying two bytes
> > at a time. Evidently, the hardware crashes if they try to access
> > a single byte.
> >
> > Here's the Ada 95 version of the original Ada83 code:
> >
> > -- Assumed visibility of Project_Types
> > procedure Copy_Double_Byte(Destination : in System.Address;
> >                            Source      : in System.Address;
> >                            Length      : in Natural) is
>
> There's about a 9 out of 10 chance that this system does not need to be
> dealing with addresses; that this way of doing things was dreamed up by
> a C person who lacked the necessary familiarity with Ada 83 to be
> competent to create this specification. I have seen this kind of misuse
> of the language far too many times for it to be likely that this case is
> different.
>
> You rarely need to use addresses in Ada; this particular example almost
> certainly did not need to use addresses even in Ada 83. Maybe you're
> stuck with it, in which case you can probably do
>
> Storage_Length : constant Storage_Count :=
>    Storage_Count ( (8 * Length + Storage_Unit - 1) / Storage_Unit);
> -- Convert Length (in 8-bit bytes) to work with Storage_Elements
>
> A : Storage_Array (1 .. Storage_Length);
> for A'Address use Destination;
> pragma Import (Ada, A);
>
> B : Storage_Array (1 .. Storage_Length);
> for B'Address use Source;
> pragma Import (Ada, B);
>
> ...
>
> A := B;
>
> --
> Jeff Carter
> "We call your door-opening request a silly thing."
> Monty Python & the Holy Grail

Re: Help with Copying Shared Memory to Local

[Randy Brukardt]

John Cupak wrote in message ...
>Jeffrey,
>
>What a refreshing solution!
>
>I don't know why they're using pointers or addresses, either. Probably,
as
>you noted, a C-hacker
>trying to write Ada.
>
>I've forwarded your suggested solution to the maintenance programmer
who
>brought the problem
>to my attention. Let's see if it flys.


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.

However, you could use pragma Atomic to help convince the compiler to do
the appropriate reads and writes. And I doubt that all of that address
stuff helps much. :-)

       Randy.



>Thanks again - Occam's razor strikes again!
>
>John
>"Jeffrey Carter" <jrcarter@acm.org> wrote in message
>news:3CED51CF.39E26FC6@acm.org...
>> John Cupak wrote:
>> >
>> > A colleague asked me to help him solve an memory copy problem.
>> >
>> > The source memory location is in a "shared" area, and the
>> > destination memory location is "local" to the application.
>> >
>> > The original code, written in Ada83, works by copying two bytes
>> > at a time. Evidently, the hardware crashes if they try to access
>> > a single byte.
>> >
>> > Here's the Ada 95 version of the original Ada83 code:
>> >
>> > -- Assumed visibility of Project_Types
>> > procedure Copy_Double_Byte(Destination : in System.Address;
>> >                            Source      : in System.Address;
>> >                            Length      : in Natural) is
>>
>> There's about a 9 out of 10 chance that this system does not need to
be
>> dealing with addresses; that this way of doing things was dreamed up
by
>> a C person who lacked the necessary familiarity with Ada 83 to be
>> competent to create this specification. I have seen this kind of
misuse
>> of the language far too many times for it to be likely that this case
is
>> different.
>>
>> You rarely need to use addresses in Ada; this particular example
almost
>> certainly did not need to use addresses even in Ada 83. Maybe you're
>> stuck with it, in which case you can probably do
>>
>> Storage_Length : constant Storage_Count :=
>>    Storage_Count ( (8 * Length + Storage_Unit - 1) / Storage_Unit);
>> -- Convert Length (in 8-bit bytes) to work with Storage_Elements
>>
>> A : Storage_Array (1 .. Storage_Length);
>> for A'Address use Destination;
>> pragma Import (Ada, A);
>>
>> B : Storage_Array (1 .. Storage_Length);
>> for B'Address use Source;
>> pragma Import (Ada, B);
>>
>> ...
>>
>> A := B;
>>
>> --
>> Jeff Carter
>> "We call your door-opening request a silly thing."
>> Monty Python & the Holy Grail
>
>

Re: Help with Copying Shared Memory to Local

[Jeffrey Carter]

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

RE: Help with Copying Shared Memory to Local

[Beard, Frank [Contractor]]

Jeffrey Carter wrote:

> A : Storage_Array (1 .. Storage_Length);
> for A'Address use Destination;
> pragma Import (Ada, A);
>
> B : Storage_Array (1 .. Storage_Length);
> for B'Address use Source;
> pragma Import (Ada, B);
>

Jeff,

Just curious.  Why the "pragma Import" on the object?

On our last Unix (HP-UX BLS) project, I wrote a generic package
that worked very similar to your suggestion.  The generic had
methods that wrappered all the appropriate OS calls for managing
the shared memory.

When the package was instantiated with the desired type, it gave
you an object of that type who's address would be mapped to shared
memory with a call to the Get_Shared_Memory method in the generic.
Once that was done, you just accessed the object just like any other, 
making it transparent to the user that it was in shared memory.

My point to this is I did a "pragma Import" on the OS calls, such as 
ShmGet (what a descriptive name), but I didn't have to do a "pragma 
Import" on the object.  What does it buy you to do the import on the
object?

Thanks
Frank

Re: Help with Copying Shared Memory to Local

[Stephen Leake]

"John R. Strohm" <strohm@airmail.net> writes:

> Ada representation specifications provide a clean way to
> tell the compiler what kind of access to use, 

This is _not_ what rep spec say. They say how to lay out the bits in
memory, not how to access them.

> and most compilers were good about following the programmer's
> wishes.

Some compilers do "what you want", but there is _no_ guarrantee in the
language for this.

If you need a 16 bit access, use assembly code. Wrap it up in a
low-level Ada subprogram, to make it easy to use.

Yes, it feels inefficient and inelegant, but it is the best approach.

-- 
-- Stephe

Re: Help with Copying Shared Memory to Local

[John R. Strohm]

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

Re: Help with Copying Shared Memory to Local

[Jeffrey Carter]

"Beard, Frank [Contractor]" wrote:
> 
> Jeffrey Carter wrote:
> 
> > A : Storage_Array (1 .. Storage_Length);
> > for A'Address use Destination;
> > pragma Import (Ada, A);
> >
> > B : Storage_Array (1 .. Storage_Length);
> > for B'Address use Source;
> > pragma Import (Ada, B);
> >
> 
> Just curious.  Why the "pragma Import" on the object?

Pragma Import (Ada, ...); tells the compiler not to initialize the
object. In many cases (including this one, most likely) no
initialization will take place anyway, but pragma Import is the way to
be sure.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail

Re: Help with Copying Shared Memory to Local

[Jeffrey Carter]

"John R. Strohm" wrote:
> 
> Jeffrey, I surmise that you have not spent a lot of time doing device
> drivers in embedded systems.

The original post discussed copying the contents of memory from one
place to another. Some of the memory was described as "shared", but no
mention was made of device drivers.

If specific machine code instructions are required to access a device,
nothing in Ada is guaranteed to give you those instructions except a
machine code insertion. Representation clauses, Atomic, Volatile, and
the like will frequently work, but you have no guarantee that what works
for a given compiler and platform will work with any other compiler or
platform, including other versions of the same compiler.

The original post clearly indicated that all that was needed to access
shared memory was a suitable address and 2-byte access. A 2-byte atomic
type a corresponding array with atomic components will produce that on
many systems. If it doesn't work for the poster's system, then a machine
code insertion is in order.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail

Re: Help with Copying Shared Memory to Local

[Pat Rogers]

"John R. Strohm" <strohm@airmail.net> wrote in message
news:EE1B58C60CD7D9ED.3DE0D594451AD094.92104DC9322C357A@lp.airnews.net...
> type x is record
>     csr: byte;
>     dr: byte;
> end record;
> for x use record at mod 2;
> for x'size use 16;

The other poster is right -- there's nothing to say that the above causes the
compiler to generate 16-bit accesses.  When you need that kind of control, you
are better off writing the machine-code insert to do it explicitly, rather than
trying to coerce the compiler to do it the way you want.  Sure, you can often
get your compiler to do what you want, until the next release!


--
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Help with Copying Shared Memory to Local

[John R. Strohm]

type x is record
    csr: byte;
    dr: byte;
end record;
for x use record at mod 2;
for x'size use 16;

Or something of that nature.

Admittedly, it has been a number of years since I last looked at Ada rep
specs.  The thing I remember most painfully was laying out the registers for
a Signetics 2681 DUART, and then writing a reusable device driver as a set
of four generics.

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:ulma9mqnj.fsf@gsfc.nasa.gov...
> "John R. Strohm" <strohm@airmail.net> writes:
>
> > Ada representation specifications provide a clean way to
> > tell the compiler what kind of access to use,
>
> This is _not_ what rep spec say. They say how to lay out the bits in
> memory, not how to access them.
>
> > and most compilers were good about following the programmer's
> > wishes.
>
> Some compilers do "what you want", but there is _no_ guarrantee in the
> language for this.
>
> If you need a 16 bit access, use assembly code. Wrap it up in a
> low-level Ada subprogram, to make it easy to use.
>
> Yes, it feels inefficient and inelegant, but it is the best approach.
>
> --
> -- Stephe

Re: Help with Copying Shared Memory to Local

[Stephen Leake]

"John R. Strohm" <strohm@airmail.net> writes:

> type x is record
>     csr: byte;
>     dr: byte;
> end record;
> for x use record at mod 2;
> for x'size use 16;
> 
> Or something of that nature.

This says that objects of type x are 16 bits in size, and located on
16 bit boundaries.

If we have the following code:

declare
   a : X;
   b : X;
begin
   a := b;
end;

The compiler is perfectly free to do two 8 bit copies. On an 8 bit
machine, that's what I'd expect!

Now consider this:

declare
   a : X;
   b : X;
   c : X;
   d : X;
begin
   a := b;
   c := d;
end;

The compiler is perfectly free to do one 32 bit copy. On a 32 bit
machine, that's what I'd hope for (not quite expect :).

Most compilers, most of the time, will do what you want. But it is
_not_ _guarranteed_ by the language.


Where I really got bit by this the first time was using a bit-mapped
rep spec to access the bits in a hardware register, which is the
natural way to do it in Ada. The compiler happily coded 8 bit accesses
to get to the bits it needed, and the hardware got thoroughly
confused. The only way to get it right was to use machine code to do a
16 bit read to normal RAM, then unchecked convert to the bit-mapped
rep spec. Then bit or byte access to the RAM copy was fine.

-- 
-- Stephe

Re: Help with Copying Shared Memory to Local

[martin.m.dowie]

"Pat Rogers" <progers@classwide.com> wrote in message
news:aPwH8.15921$1U4.2841103386@newssvr30.news.prodigy.com...
> "John R. Strohm" <strohm@airmail.net> wrote in message
> news:EE1B58C60CD7D9ED.3DE0D594451AD094.92104DC9322C357A@lp.airnews.net...
> The other poster is right -- there's nothing to say that the above causes
the
> compiler to generate 16-bit accesses.  When you need that kind of control,
you
> are better off writing the machine-code insert to do it explicitly, rather
than
> trying to coerce the compiler to do it the way you want.  Sure, you can
often
> get your compiler to do what you want, until the next release!

Unless you have fixed your compiler at a particular version - not an
uncommon practice. Slap
a _huge_ comment about the potential non-portable nature of the code and
more detail in a
design document and most of us mere mortals would be happy.

(Quicker than finding someone with the right assembler skills too :-)

Re: Help with Copying Shared Memory to Local

[Robert Dewar]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3CED51CF.39E26FC6@acm.org>...

> There's about a 9 out of 10 chance that this system does not need to be
> dealing with addresses; that this way of doing things was dreamed up by
> a C person who lacked the necessary familiarity with Ada 83 to be
> competent to create this specification. I have seen this kind of misuse
> of the language far too many times for it to be likely that this case is
> different.

OK, so we await your Ada 83 solution, given this criticism

> A : Storage_Array (1 .. Storage_Length);
> for A'Address use Destination;
> pragma Import (Ada, A);
> 
> B : Storage_Array (1 .. Storage_Length);
> for B'Address use Source;
> pragma Import (Ada, B);

OUCH! This is erroneous code in Ada 83, so surely you are not saying that
an Ada 83 programmer should have used this approach?

Re: Help with Copying Shared Memory to Local

[John Cupak]

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
>
>

Re: Help with Copying Shared Memory to Local

[Jeffrey Carter]

Robert Dewar wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3CED51CF.39E26FC6@acm.org>...
> 
> > A : Storage_Array (1 .. Storage_Length);
> > for A'Address use Destination;
> > pragma Import (Ada, A);
> >
> > B : Storage_Array (1 .. Storage_Length);
> > for B'Address use Source;
> > pragma Import (Ada, B);
> 
> OUCH! This is erroneous code in Ada 83, so surely you are not saying that
> an Ada 83 programmer should have used this approach?

Pragma Import was not very portable in Ada 83, either. Obviously this
was not intended for Ada 83.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: Help with Copying Shared Memory to Local

[John Cupak]

"John Cupak" <Jcupak744@attbi.com> wrote in message news:<hoWH8.4604$jv5.1045024@typhoon.ne.ipsvc.net>...
> 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

Well, I talked to the programmer who posed this problem to me, and he
said that the computer hardware is "Standard VME", but that the shared
memory card is old, poorly-documented, and "home-brewed". He promised
to get me what information he can on the memory card in a day or so.

He also mentioned when he created two byte arrays and mapped them to
the shared and local memory, the compiler would NOT let him write
A:=B, but he COULD write A(I):=B(I), where the index, I, was a
double-byte index. I suspect there's some 16-bit addressing / transfer
going on at the hardware board level.

We'll know more in a day or two.

John