Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!sirius!jeremy From: jeremy@cs.ua.oz.au (Jeremy Webber) Newsgroups: comp.sys.transputer Subject: Re: I/O Calls on the Transputer and General Call for Benchmarks Message-ID: Date: 31 Jul 90 00:07:25 GMT References: <9007271900.AA09549@tcgould.TN.CORNELL.EDU> <8932@ganymede.inmos.co.uk> Sender: news@ucs.adelaide.edu.au Organization: Digital Arts Film and Television Lines: 45 In-reply-to: davidb@brac.inmos.co.uk's message of 28 Jul 90 18:11:00 GMT In article <8932@ganymede.inmos.co.uk> davidb@brac.inmos.co.uk (David Boreham) writes: In article <9007271900.AA09549@tcgould.TN.CORNELL.EDU> koontz%capvax.decnet@CAPSRV.JHUAPL.EDU ("CAPVAX::KOONTZ") writes: ... >20Mbps), Inmos 'sez that the B014 VMEbus interface will only handle around >150KB/sec. If the interface could handle the link speed, we might see up to an ^^^^^^^ Well actually the link adaptor will do ~800K. ... Problems interfacing transputers to general purpose computers: 1. All software known expects to talk to a LINK and be a BYTE stream. 2. Link adaptors (the present one, in C011 and C012 guise) are not suitable for interfacing to computers. They are basically a toy usefull for talking to slow dumb peripherals. The big lack is BUFFERING and their 8-bit ness. I was faced with the task of interfacing a B014 to an SGI Personal Iris, including writing device drivers from scratch. Fundamentally, the reason the B014 is so slow is because it does 8bit data transfers, and has no support for DMA. On our 32 bit R2000 based machine this is a _real_ lose, both in link speed and bus bandwidth consumed. The fact that the link semantics are a byte stream have nothing to do with it. RS232 connections are also byte streams, but serial controllers which do word tranfers over the bus, with DMA and siloing, have been around for donkey's years. Whoever designed the B014 was either designing a toy or hadn't read the literature. As an aside, the device driver was easy to write, and does polling rather than interrupts because there are less instructions needed per byte transferred (when there is data available) this way. This does, however, make the device driver unusable on a multi-user computer because the CPU spins when there is no data available (yes, the driver does relinquish the CPU after a certain number of spins). -jeremy webber -- -- Jeremy Webber ACSnet: jeremy@chook.ua.oz Digital Arts Film and Television, Internet: jeremy@chook.ua.oz.au 60 Hutt St, Adelaide 5001, Voicenet: +61 8 223 2430 Australia Papernet: +61 8 272 2774 (FAX)