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,be920da40970e1c2
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2000-11-02 11:59:55 PST
Path: 
 supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!europa.netcrusader.net!205.252.116.205!howland.erols.net!newsfeed.mindspring.net.MISMATCH!news.mindspring.net!firehose.mindspring.com!not-for-mail
From: Al Johnston <sofeise@mindspring.com>
Newsgroups: comp.lang.ada
Subject: Re: gnat/ppc and a32 blt transfers
Date: Thu, 02 Nov 2000 14:58:36 -0500
Organization: MindSpring Enterprises
Message-ID: <3A01C76C.86CEA181@mindspring.com>
References: <3A007357.FF3475A0@mindspring.com>
NNTP-Posting-Host: d1.56.4d.53
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server-Date: 2 Nov 2000 19:58:43 GMT
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
Xref: supernews.google.com comp.lang.ada:1729
Date: 2000-11-02T19:58:43+00:00
List-Id: <comp.lang.ada>


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