Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!vax.oxford.ac.uk!ADRIAN From: ADRIAN@vax.oxford.ac.uk Newsgroups: comp.sys.transputer Subject: D700E. TDS3. New release of Transputer Development System. Message-ID: <27620.9008021506@prg.oxford.ac.uk> Date: 2 Aug 90 16:07:46 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 169 >>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] -----------------------------------------------------------------------------