🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.transputer
Article #836

Re: I/O Calls on the Transputer and General Call for Benchmarks

#836
From: Jeremy Webber
Date: Tue, 31 Jul 1990 00:07
45 lines
2835 bytes
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)
Technical Details
Message-ID: <JEREMY.90Jul31093725@chook.ua.oz.au>
Path: arc1-ca.pugleaf.net!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
References: <9007271900.AA09549@tcgould.TN.CORNELL.EDU> <8932@ganymede.inmos.co.uk>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <JEREMY.90Jul31093725@chook.ua.oz.au>
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