gnat/ppc and a32 blt transfers

gnat/ppc and a32 blt transfers

[Al Johnston]

We are running gnat/solaris->ppc.  our cpu cards are mvme2700 in a 64x
vme chassis.

I am having trouble with 64 bit accesses from the cpu to some of our
vme (slave) cards.  The slaves do not like the MBLT (AM=0c) accesses 
that the compilers code is causing to be used on the bus.

So what I need to do is write my own ":=" and relational operators
that access the 64bit entity via two 32 bit reads/writes.

I was wondering if this would be an appropriate place you use
ada95's "controlled types"?

If so, how much overhead does this involve.


thanks.

-al

Re: gnat/ppc and a32 blt transfers

[Robert Dewar]

In article <3A007357.FF3475A0@mindspring.com>,
  Al Johnston <sofeise@mindspring.com> wrote:
> I am having trouble with 64 bit accesses from the cpu to some
of our
> vme (slave) cards.  The slaves do not like the MBLT (AM=0c)
accesses
> that the compilers code is causing to be used on the bus.
>
> So what I need to do is write my own ":=" and relational
operators
> that access the 64bit entity via two 32 bit reads/writes.

If you need to control the exact instruction sequences that
a compiler is generating, do it properly, with machine language
inserts. Do not fiddle around with the compiler to try to get
it to produce the code you want. That's a recipe for
non-portable code. If you try to fool the compiler, then
it is easily possible that some later version may be cleverer
and undo your subterfuge.

I have seen nothing but trouble caused by undocumented and
unwarranted assumptions about the exact sequence of machine
language instructions.

One remarkable example with one of our customers was in the
following situation:

   type x is array (integer range <>) of boolean;
   pragma Pack (x);

   subtype y is array (0 .. 31);

   z : y;
   for z use at ...

   ...

   z (4) := ....;

The code malfunctioned when ported from VADS to GNAT. Why?
Because VADS chose to do load-word/modify bit/store-word,
and GNAT chose to do load-byte/modify bit/store-byte.

Both are perfectly fine sequences of instructions, there is
no reason to prefer one over the other from the compiler's
point of view.

UNFORTUNATELY: the address clause was placing the memory in
some strange home brewed memory mapped I/O device, which only
happened to recognize word accesses (this was on a 68K) and
did not recognize byte accesses (but indeed simply did something
weird, since the byte access case had been left as don't care
since probably the hardware folks had been told -- don't worry
we will only do word accesses.

Easy enough to fix once found, but not at all easy to find.

If you want to write in Ada, write in Ada, if you want to
write machine code, write in machine code!

> I was wondering if this would be an appropriate place you use
> ada95's "controlled types"?

No, it is not!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: gnat/ppc and a32 blt transfers

[DuckE]

Should't

 pragma Atomic( variable );

cause accesses to a variable to be performed as a single operation?

While I would not expect this to work for the component of a packed boolean
array, since  element is not individually addessable (on most
architectures), I would expect this functionality using types that are
individually addressable.

For example, on an architecture where integers are 32 bit values I would
expect the following declarations:

  memValue : Integer;
  FOR memValue'ADDRESS USE
System.Storage_Elements.To_Address( 16#FFFE0000# );
  PRAGMA Atomic( memValue );

To generate code that uses 32 bit accesses to memValue.

Since GNAT supports Annex C, and this behaviour is described in C.6.15, I
would expect this behavior.

Am I missing something?

SteveD

Re: gnat/ppc and a32 blt transfers

[Robert A Duff]

"DuckE" <nospam_steved94@home.com> writes:

> Should't
> 
>  pragma Atomic( variable );
> 
> cause accesses to a variable to be performed as a single operation?

Yes.

And if the hardware can't do it, you'll get a compile-time error.

- Bob

Re: gnat/ppc and a32 blt transfers

[Al Johnston]

In my case, atomic would be going the wrong way... the vme slave card
can not do any form of 64 bit transfers.

I tried to decode the assembly for this line of code causing the MBLT,
but
could not get anywhere... It probably doesn't matter.  the opcode access
the processor bus, which then goes across a pci bridge chip, and then
across a vme bridge chip.  It is this last chip that actually decides
that the transfer should be done as a MBLT.

Fortunately the vme bridge chip had a "no blt" bit which when set
caused the access to no longer be a MBLT, and more importantly,
to work!

I am not sure what to make of the "if you want to program in asm..."
remark....  All I was doing here was accessing memory...

-al

Re: gnat/ppc and a32 blt transfers

[Robert Dewar]

In article <3A01C76C.86CEA181@mindspring.com>,
  Al Johnston <sofeise@mindspring.com> wrote:
> I am not sure what to make of the "if you want to program in
> asm..." remark....  All I was doing here was accessing
> memory...


There is no such thing as "accessing memory" in Ada, the
definition of the Ada language is at a much higher semantic
level, and the compiler can produce any sequence of code
that meets the semantic requirement using the standard
instruction set of the machine. if you have some definite
requirement, as in this case, for issuing specific sequences
of machine instructions, that should be programmed in
machine language insertions, or in assembly language.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: gnat/ppc and a32 blt transfers

[Al Johnston]

> There is no such thing as "accessing memory" in Ada, the

More sloppy thinking on my part... Your meaning is clear to
me now.

Would you mind fielding a related question?  Is there
any way to associate the ":=" operator with such a
routine?  I have always been puzzled why we can associate
the relational tokens (>,<,=, etc.) to a function... but
not assignment... and never sure it it was really not in
the language or if I was just missinging it.  Anyway, that 
was the real point of my inquiry about controlled types.
A way to associate code with the assignment operator.

thanks.

-al

Re: gnat/ppc and a32 blt transfers

[Florian Weimer]

Al Johnston <sofeise@mindspring.com> writes:

> A way to associate code with the assignment operator.

There is no assignment operator in Ada, i.e. what you are trying to do
is impossible.

Re: gnat/ppc and a32 blt transfers

[David Starner]

On Sat, 04 Nov 2000 05:02:44 GMT, Robert Dewar wrote:
>In article <3A01C76C.86CEA181@mindspring.com>,
>  Al Johnston <sofeise@mindspring.com> wrote:
>> I am not sure what to make of the "if you want to program in
>> asm..." remark....  All I was doing here was accessing
>> memory...
>
>
>There is no such thing as "accessing memory" in Ada, the
>definition of the Ada language is at a much higher semantic
>level, and the compiler can produce any sequence of code
>that meets the semantic requirement using the standard
>instruction set of the machine.

May I point out that this is true for most languages, including
C. The Linux kernel people have got burnt several times assuming
otherwise and then the gcc people changed the compiler on them.

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
As centuries of pulp novels and late-night Christian broadcasting have taught 
us, anything we don't understand can be used for the purposes of Evil.
	-- Kenneth Hite, Suppressed Transmissions

Re: gnat/ppc and a32 blt transfers

[Robert Dewar]

In article <8u1k6c$9ic1@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
> May I point out that this is true for most languages,
> including C. The Linux kernel people have got burnt several
> times assuming otherwise and then the gcc people changed the
> compiler on them.

Indeed, there is nothing special about Ada here, and yes, indeed
the situation is exactly the same in C (although C programmers
tend to be less aware of the boundary between what works and
what is defined in the language).

One interesting difference between Ada and C here is that
the Ada RM specifically recognizes that a compiler must provide
an appropriate mechanism for insertion of machine language
statements (assuming the systems programming annex is
implemented). Of course these mechanisms are not portable
(not even between different compilers on the same machine,
except in the case of the Motorola 88000 where the ABI specified
exactly the form of package Machine_Language for Ada compilers.
There is no such requirement in C as far as I remember (I do
not have the C standard at hand to double check).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: gnat/ppc and a32 blt transfers

[David Thompson]

Robert Dewar <robert_dewar@my-deja.com> wrote :
...
> the Ada RM specifically recognizes that a compiler must provide
> an appropriate mechanism for insertion of machine language
> statements (assuming the systems programming annex is
> implemented). Of course these mechanisms are not portable
...
> There is no such requirement in C as far as I remember (I do
> not have the C standard at hand to double check).

C (ISO 9899:1999) does not require anything, although in
_informative_ Annex J Portability Considerations it lists
asm ( string-literal ); as a common extension.

C++ (ISO 14882:1998) specifies that same keyword and syntax
as standard, with the contents of the string (that is, the actual
assembler syntax) implementation defined; an implementation
defining that the contents are ignored would presumably be legal.

--
- David.Thompson 1 now at worldnet.att.net

Re: gnat/ppc and a32 blt transfers

[tmoran]

>>definition of the Ada language is at a much higher semantic
>>level, and the compiler can produce any sequence of code
>May I point out that this is true for most languages, including C.
  But, but, but they told me C was a fancy assembler...
;)