jdr@gec-rl-hrc.co.uk (John Robson) (03/15/90)
There have been a few brief references recently to the "link.c" interface standard developed by Inmos. Can anyone out there enlighten us with some more details? Thanks, John// =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Robson | Phone: +44 1 908 9220 (direct dial) | | Senior Research Engineer | Telex: 923429 GECLAB G | | GEC Hirst Research Centre | Fax: +44 1 904 7582 | | East Lane |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=| | Wembley | uucp: uunet!mcvax!ukc!gec-rl-hrc!jdr | | Middlesex HA9 7PP | JANET: jdr@uk.co.gec-rl-hrc | | United Kingdom | ARPA: jdr@gec-rl-hrc.co.uk | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
braner@TCGOULD.TN.CORNELL.EDU (Moshe Braner) (03/16/90)
I'll leave it to the Inmos people to tell us how to get an "official" copy of the semi-standard. It is a set of C function calls for accessing the transputer link(s), something like this: int ld = OpenLink (char * "linkname"); int ResetLink (int ld); int bytes_written = WriteLink (int ld, char *buf, int nbytes, int timeout); int bytes_read = ReadLink (int ld, char *buf, int nbytes, int timeout); int CloseLink (int ld); and so on. If all board makers would supply you with a driver that boils down to those same calls, it would be easy to link to your code unchanged. I have implemented extensions to the link.c calls, and have suggested (still suggesting) adding them to the standard. The extensions include: An additional argument to OpenLink: int ld = OpenLink (char * "linkname", int flags); - the flag bits are OL_RDONLY, OL_DMA, etc. int StartRead() - same a ReadLink(), but may return before the transfer is done, to be finished in the background. (Additional details on how to find out when the transfer is done, install an interrupt handler for when it's done, etc, skipped here...) And of course there is a StartWrite(), etc. For IBM-PCs: int FarRead (int ld, char far *buf, int nbytes, int timeout); int FarWrite (int ld, char far *buf, int nbytes, int timeout); ^^^ (This is not needed in the large-data memory models, but I need to use far buffers in a small-model program.) At another level, I have suggested (and implemented) another standard, for MS-DOS, that operates at a lower level than the link.c standard, i.e., is complementary to it. The suggestion is to implement link.c via SOFTWARE INTERRUPTS, to be handled by a memory-resident (TSR) driver. (I use the interrupt number 65 hex, is that a good choice?) The advantage of this is that the board vendor does not need to supply the driver in source form, and the user DOES NOT NEED TO LINK the driver itself in. Instead, if the software interrupt interface is standard, the user links a stub interface that is GENERIC AND PUBLIC, that just translates OpenLink() to a certain software interrupt protocol, etc. The application thus created will WORK WITHOUT CHANGE with ANY board for which the appropriate memory-resident driver is available and installed. The downside is some added overhead (execution time) for the software interrupt, about 200 microsecs on an 8 MHz PC-AT. Not too bad, in my view, since it is insignificant on the case of the transfer of large blocks of data, and irrelevant in the case of an interactive program. - Moshe