Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!indetech!daver!bungi.com!news From: gs@vw25.chips.com (George Scolaro) Newsgroups: comp.sys.nsc.32k Subject: Re: SCSI Woes, revisited Message-ID: Date: 8 May 91 21:13:54 GMT Sender: news@daver.bungi.com Lines: 49 Approved: news@daver.bungi.com [In the message entitled "SCSI Woes, revisited" on May 1, 23:03, randy hyde writes:] > > I have a couple of quick questions on the subject. > > The manual states that you shouldn't use interruptable instructions for > pseudo-DMA (I assume this means MOVSi). What about MOVMD? Is this > instruction kosher? What is the problem with an interruptable instr. > like MOVS? An interruptible instruction may on returning from the trap handler re-transfer part of the data that was already transferred prior to the interrupt. This will cause extra data to be read or written to the peripheral device - not a good idea! I don't know if MOVMD is an interruptible instruction, maybe someone from NS can supply that information. Anyhow, more importantly, on the 32532 instructions like MOVD are just as fast as the more complex MOVSi or MOVMi instruction, as long as they are in the instruction cache - which would be the case. > Also, since the cache is write-though, I assume that I do not need to > increment the destination pointer when writing to the pseudo-DMA area > (except one bump at the end of the operation to prevent a read from > that same location later on causing a problem). Is this correct? Sounds right. > While on the subject, what's wrong with simply disabling the data cache > while accessing the pseudo-DMA area? Can't you disable the data cache and > leave the instr cache going? This would seem to produce the best performance > anyway since constantly reading from (or writing to) the pseudo-DMA area would > tend to invalidate a lot of the cache. Is this a correct assumption? Not necessarily, since disabling the data cache would also cause the memory side of the transfer to not be cached. This would reduce the transfer performance - we rely on the cache doing a line fill on a read - 16 byte transfer (more important on read from memory and write to peripheral). Also, if you just disable the cache and then re-enable it - it will be flushed, to ensure coherency - locking it might be better (though I'm not sure if you can lock the data cache - you certainly can for the instruction cache). The bottom line is try and see which is fastest. Also, make sure you have a 32532 data booklet on hand and read the fine print very closely! It always amazed me to see the way NS did their 32k data sheets - the most important information was always printed in the smallest type! best regards, -- George Scolaro (gs@vw25.chips.com) Chips & Technologies (408) 434-0600 3050 Zanker Road San Jose, CA 95134