ADRIAN@vax.oxford.ac.uk (08/02/90)
>>In reply to:- Michael from Manchester asking about D700E
Transputer Development System (TDS3) "D700E" - rather long!
============================================================
I was involved in beta testing the new release, so I have been using it for
several months.
The TDS ("Transcendent Development System") has been improved and upgraded
in many ways, and you would almost certainly wish to have the new version.
I believe that there is only a nominal charge to upgrade from previous
versions.
Perhaps the first thing to explain is that this release is designed to bring
the TDS into conformity with the Toolset. Now many of us think that this is
the wrong way around! We would like the Toolset to be upgraded to achieve the
heights of the TDS. Recently, I have been forced to use the Toolset, and it
is like going back to the stone age! This is for writing in occam. I would
make no comment about using the Toolset for c, Pascal, Fortran, or whatever.
Except wondering how you can manage without a folding editor after you have
once been exposed to such!
In passing, I will just say that I *am* using a Toolset for occam: we are
testing a pre-release stand-alone INMOS occam compiler. But please don't
ask about that: I am not sure that INMOS wishes to publish anything yet.
Although it is common knowledge on this net that INMOS have a new in-house
occam compiler written in C. Now you know that it is being tested outside
Inmos as well.
Lest TDS fanatics panic, the new TDS3 has on the whole been enhanced. The
changes to match the Toolset are
1) Use of Iserver.
2) Extension of libraries to include toolset style procedures and protocols.
3) Support for the SP protocol for communication with iserver.
4) Extensions to the folding editor to support Toolset source files.
I will expand a little:
Iserver
======
The toolset uses a host program, written in C, to communicate with the
host. It is normally set up to "talk" to a link adapter. It is Inmos
policy that this should be as portable as possible, and to make as few
assumptions as possible about the host. Believe it or not, it involves
polling , **even by the transputer***!!
You may well think that there is even more evidence of the spread of
BSE in Britain, especially among senior Inmos staff. (BSE =Bovine Spongiform
Encephalitis, "Scrapie" to you, a disease of cattle possibly able to cross
infect humans....)
For example, to read the keyboard via the iserver there are but two facilities:
"Getkey" and "Pollkey". It is necessary to call "Pollkey" repeatedly, and then
"Getkey". "Getkey" does not 'reply' until there is a keystroke available.
This has many implications of course, not least of which is very poor use of
what little bandwidth is available with a link adapter connection to a host!
But by far the most serious aspect is that the naive use of of 'reading' the
keyboard has a side effect: CPU resources are consummed in polling rather than
the process being descheduled until the communication occurs. In that general
sense the occam semantics of communication are broken.
Now having said that, the outstanding implementor has done his very best to
overcome these horrors! First, he has retained the TDS EXE enviroment:
within an EXE all the usual screen & keyboard channels are available, and
they retain the proper occam semantics. The EXE environment actually maps
these proper communications onto the SP protocol, but in such a way that
the semantics are retained. (Obviously polling is done at set intervals; at
other times the relevant process is descheduled. It is even possible to
modify the polling interval. But all this is normally hidden from the user.)
You can, in addition, use the SP protocol, or suitable subsets. Normally you
will use a library procedure rather than handling SP protocol directly.
The TDS now includes all the Toolset libraries as well as the existing TDS
libraries.
But iserver is not all bad news: it does provide many extra facilities.
These include standard portable ways of accessing host files, host clock,
and even a general host system call. And ANSI screen escape sequences work.
It means that a program written with the SP protocol should work either in
the TDS, the Toolset, or 'stand-alone'. The later refers to a tool within
the TDS which makes it very easy to convert a TDS EXE into a "standard hosted
procedure". That is a lump of code that is loaded onto a transputer and then
interacts with the iserver.
Please do not forget that the TDS is an enviroment for developing custom
systems. None of the above in any way constrains you in writing for any
environment or server whatsoever. You will have to provide your own server
perhaps, or maybe use a server from the previous TDS release, or one of the
many commercial enhancements. While you are running the TDS3 itself, you
will need iserver, but your target programs are not constrained in any way.
Summary for iserver:-
Advantages: portable; provides general facilities for host access;
easy to write common programs for TDS, Toolset and standalone.
Disadvantages: Very poor use of hardware so inefficient; apparently designed
with no regard for mathematical model of communication.
2,3) Extension of Libraries
=========================
Libraries are provided that map to the SP protocol facilities. They are
the same or enhancements of those provided with the Toolset.
4) Folding Editor Enhancements
==============================
The editor has been extended to handle Toolset source folds. So you can now
use the wonderful TDS folding editor with the Toolset! This makes the Toolset
almost tolerable! Now if we could just call the Toolset compiler and other
utilities with a single keystroke, maybe after editing a pop-up parameter
fold, the Toolset might be lest cumbersome! The editor also has new features
including a new macro option.
Furthermore, the source of the editor is now supplied with the standard TDS.
Thus you can add extra facilities. One day, I intend to add regular
expressions. They are already implemented in another of the occam tools, so
that should be quite simple.
My one reservation about the editor is in fold navigation. It is still a pain
to move several levels down, back up, and down again. This was discussed a
good deal in beta-testing, but the amount of effort involved in adding
better features was deemed too great for this release.
Compiler
========
The compiler has been updated. It now includes support for all the new
transputers. (No, the H1 does not appear on the list!) It also now handles
"transputer classes". Transputers share the almost same instruction set
which is word length independant. But allocation of workspace and such does
require information on wordlength. And floating point units are present only
on some chips. This allows transputers to be classified in broad classes for
many compilation purposes (TA,TB,TC,....). The compiler now supports this mode
as well as individual versions.
===============================================================================
There are many other additions and enhancements, and the TDS still provides
a vast resource of occam programs. Order yours today!
This is of course just a personal opinion. Toolset fanatics should not take
offence! The TDS has been unpopular with some people who do not like novelty.
My experience is that those who persevere come to be very enthusiatic. And
among occam uses it is almost essential, primarily in virtue of the folding
environment. My private researches among transputer users at several
conferences is that the vast majority of people writing in occam use the TDS,
and are very happy with it. The Toolset is of course popular with those used
to C particulary in a Unix enviroment where they wish to continue to use the
familiar Unix tools.
I hope that what I have said is reasonably correct, but I offer no guarantee.
Adrian Lawrence
----------------------------------------------------------------------------
ADRIAN @ UK.AC.OXFORD.VAX Microprocessor Unit, Oxford University,
13,Banbury Road, Oxford, Oxon. OX2 6NN. UK.
----------------------------------------------------------------------------
EARN/Bitnet: ADRIAN%UK.AC.OXFORD.VAX@AC.UK
{EARN node UKACRL}
ARPA: ADRIAN%VAX.OXFORD.AC.UK
ACSnet: adrian@vax.oxford.ac.uk@au.oz.munnari
[ean.ac.uk%nummari.cs.mu]
-----------------------------------------------------------------------------