HDTenEightyP/NetNews huggingface dataset:
From: steved@inmos.co.uk (Stephen Doyle)
Newsgroups: comp.sys.transputer
Subject: Re: T9000 and OCCAM 3
Date: 5 Oct 92 09:50:52 GMT
Organization: The Internet

MICHAEL <bane@vortex.mathematics.manchester.ac.uk> writes

> Anybody have progress deadlines for occam-3? Or latest info
> on T9 release?
> 
> [Are their arrivals interconnected and have they deadlocked?]
> 

This message was circulated on comp.sys.transputer following some discussion
of a T9000 sample die handed to Parsytec at the TAT'92 conference in
Aachen.

This message should clarify the true situation behind David May's presentation
of a T9000 alpha device to Parsytec at TAT '92 (Aachen).

The device in question was an open package containing a real T9000 alpha die
which was bonded out. It was the intention that this device should be used
for display purposes only and not intended to be plugged into a board,
and was presented to Parsytec who were the organisers of TAT '92 as David
May was unable to stay for the full duration of the conference.

We have been testing fully packaged T9000 alpha devices in our 
laboratories in Bristol as part of the normal product development cycle.
We have kept our transputer customers up to date with progress on the 
T9000 developments and have made provision for a special customer 
laboratory in Bristol where major customers can gain access to T9000 
alpha silicon and further their own product development.

The T9000 alpha silicon was intentionally produced without the data links.
The T9000 beta silicon which is going through the fab at the moment has 
all the functional blocks (including VCP and data links) of the T9000 
integrated (as defined in the technical disclosure of April 1991).

------------------------------------------------------------------------

Now, on the subject of OCCAM 3.

The T9000 does not depend on the OCCAM 3 language in any way, ANSI C and 
OCCAM 2 will both exploit the T9000 and Toolsets for the T9000 will be 
commercially available when T9000 hardware products are.

OCCAM 3 is still in the draft language stage, elements of the OCCAM 3
language will be introduced into OCCAM 2 compilers during 1993 to 
support
    - User defined types
    - Records
    - Removing requirement for explicitly typing literals
    - Allow arithmetic on BYTE types
    - Allow FUNCTIONs to return fixed length arrays
    - Permit the dropping of FROM and FOR in segments of arrays

OCCAM 3 is in our longer term plans, based on ANDF technology for a wide
range of different computer architectures.

regards,

Steve Doyle

Newsgroups: comp.sys.transputer
From: schimpf@azu.informatik.uni-stuttgart.de (Stefan Schimpf)
Subject: Meiko CS Tools question
Organization: Informatik, Uni Stuttgart, Germany
Date: Tue, 29 Sep 1992 11:45:29 GMT

Is it possible on a Meiko MK 255 board with the Meiko CS Tools 1.15
software package to use all the 4 links of a transputer as
(bidirectional) hardchannels and do the whole communication using the
low-level primitives cread(), cwrite()?

I've been trying to set up processes that way, but without success:
there were always 2 Links needed for "datalinks" of CSN Processes, in
spite of the fact that my processes did not use virtual channel
communication. Even booting a process which did nothing at all needed
a manually set up CSN connection, without manually set up CSN
connection booting failed with an error message.

Who can help? Thanks in advance.

 ______________________________________________________________________

 Stefan Schimpf                             phone: (+49 711) 7816 409    
 Universitaet Stuttgart                       fax: (+49 711) 780 1044 
 Institut fuer Informatik
 Breitwiesenstr. 20-22
 7000 Stuttgart 80
 Germany                          schimpf@informatik.uni-stuttgart.de
 ______________________________________________________________________


Newsgroups: comp.sys.transputer
From: muenkel@tnt.uni-hannover.de (Heiko Muenkel)
Subject: Re: Sbus to link
Reply-To: muenkel@tnt.uni-hannover.de
Organization: Universitaet Hannover, Theoretische Nachrichtentechnik
Date: Wed, 30 Sep 1992 11:18:13 GMT

In article AA04607@ra.abo.fi, tbjorkho@RA.ABO.FI (Tom Bj|rkholm AT) writes:
>Does anyone know about a cheap Sbus to link board that I could 
>put into my Sun Sparc? (I have some old B004 boards with a power
>supply, but I would like to program them from my Sparc.)
>
>Of course the board has to come with a device driver and a link 
>interface module.
>
>
>Tom Bjorkholm
>Process Design Laboratory             Phone: +358 21 654 863
>Department of Chemical Engineering    Fax:   +358 21 654 479
>Abo Akademi University                Internet: tbjorkho@ra.abo.fi
>Biskopsgatan 8                           or:    tbjorkholm@finabo.abo.fi
>SF-20500 Abo                          Bitnet:   TBJORKHOLM@FINABO
>FINLAND                               Nordunet: ABOVAX::TBJORKHOLM

I don't know what is cheap, but we use the BBK-S4 from
Parsytec GmbH
Jlicher Str. 338
D-5100 Aachen
in Germany.
It is an Interface between Sbus-Systems and transputer systems with
4 Links. The product includes Parsytecs Basic Transputer System Software
with functions like OpenLink, ReadLink etc., but I think that you need
also the INMOS iserver modified by Parsytec for the BBK-S4. We work
with the INMOS-C-Toolset modified and shipped from Parsytec which includes
an iserver for the BBK-S4.

---
________________________________________________________________________________

Dipl.-Ing. Heiko Muenkel           Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
muenkel@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49-511-762-5333           D-3000 Hannover 1
phone:  +49-511-762-5323           Germany
________________________________________________________________________________
From: steved@inmos.co.uk (Stephen Doyle)
Newsgroups: comp.sys.transputer
Subject: More T9 info
Date: 6 Oct 92 09:28:13 GMT
Organization: The Internet

scott@cannon.cs.usu.edu (Scott Cannon) writes

> Stephen Doyle writes in response to a request for info on the T9;
> 
> >... a T9000 sample die handed to Parsytec at the TAT'92
> >conference in Aachen ...
> 
> Progress on the T9?  Alpha sample dies seen at TAT 92?  I remember 
> seeing this sample die of the T9 early in 91!
> 
> s. cannon.

I don't know what you saw early in '91 but it wasn't a T9 alpha die, 
it could have been one of the early test chips - either for cache or
links (most likely the links).

Steve
Newsgroups: comp.sys.transputer
From: davidb@inmos.co.uk (David Boreham)
Subject: Re: T9 samples
Reply-To: davidb@inmos.co.uk (David Boreham)
Organization: INMOS Limited, Bristol, UK.
Date: Tue, 6 Oct 1992 09:16:14 GMT

In article <9210051449.AA01971@cannon.cs.usu.edu> scott@CANNON.CS.USU.EDU (Scott Cannon) writes:
>Stephen Doyle writes in response to a request for info on the T9;
>
>> ... message was circulated on comp.sys.transputer following some 
>>discussion of a T9000 sample die handed to Parsytec at the TAT'92
>>conference in Aachen.  The device in question was an open package 
>>containing a real T9000 alpha die which was bonded out. It was the
>>intention that this device should be used for display purposes only ...
>
>Progress on the T9?  Alpha sample dies seen at TAT 92?  I remember 
>seeing this sample die of the T9 early in 91!
>
                                   ^^^^^^^^^^NOT !

-- 
David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb
Bristol,  England            |     (us): uunet!inmos.com!davidb
+44 454 616616 ex 547        | Internet: davidb@inmos.co.uk
Newsgroups: comp.sys.transputer
From: alf@uni-paderborn.de (Alf Wachsmann)
Subject: Re: Transputer simulator for SUN
Reply-To: alf@uni-paderborn.de
Organization: Uni-GH Paderborn, Germany
Date: Tue, 29 Sep 1992 08:26:40 GMT


In article I wrote:
|> 
|> Hi,
|> 
|> assumed
|> 1. I have a SUN but no Transputer-Board and
|> 2. I want to compile OCCAM programs for Transputer-Networks and
|> 3. I want to test if the programs are correct
|> 
|> What can I do?


The main hint was given by Iain Phillips (Iain.Phillips@cs.man.ac.uk)
who suggested to use the Toolset "isim" simulator.

This program simulates a T425-Transputer on a SUN and it IS
possible to simulate great transputer networks if you set
the UNIX environment variables IBOARDSIZE to something large.

Additionally you have to declare the memsize in the .pgm-file
sufficiently large (e.g. SET Root(type, memsize := "T425", 104*mega) ).

I tried it with a 26 Transputer network without any problems!


Many thanks to Ian,

                          Alf.


-- 
*     Alf Wachsmann                | Uni/GH Paderborn                  *
*                                  | FB 17 Informatik                  *
*     e-mail: alf@uni-paderborn.de | Warburger Str. 100                *
*     Phone:  +49 5251 60 3312     | D-W-4790 Paderborn                *
*                                  | Germany                           *
From: hboden@leibniz.fb5 (Harald Boden)
Newsgroups: comp.sys.transputer
Subject: Re: T9000 Availability
Date: 30 Sep 1992 13:48:33 GMT
Organization: University of Siegen
Distribution: world
Reply-To: hboden@leibniz.fb5
NNTP-Posting-Host: leibniz

I participated in last weeks TAT'92, the german
transputer users conference.
David May gave a talk on transputers in general.
His talk was similar to the one he held in 1991
(nothing new). In 1991 he spread some vague ideas 
on pipelining and modular chip design etc. These ideas
were missing this year. He gave no outlook on
future Transputer generations, except: improved technology
will deliver faster chips (higher frequency) with faster links.
He stated that they will develop future chip generations,
if the market demands them. ...
He showed one slide of the T9000 alpha series (with missing
virtual channel processor) and introduced into the chip's building
blocks. Thereafter he handed one sample of the
alpha series (sic!) to a representative of Parsytec GmbH.
He stated that the beta series was still under production
at that time. 
According to David May, testing of the chip will continue, and it
is only a question of time until we will see a working T9000.
With a little luck (according to D. May), we will see some
working chips in November.

H. Boden
Uni - GH Siegen; Wirtschaftsinformatik
Newsgroups: comp.sys.transputer
From: luigi@pical2.uucp (Luigi Rizzo)
Subject: isim availability
Organization: Dip. di Ingegneria dell'Informazione, Univ. di Pisa (ITALY)
Date: Tue, 29 Sep 1992 18:49:39 GMT


Recently there has been some discussion on isim. As pointed out by some
users, the Unix (well, SUN) version has some advantages over the real
thing because it can emulate a system with a lot of memory (if I'm not
wrong, limited only by swap space ?); I don't think the
Transputer-based isim (the one shipped with MSDOS systems) has this
ability.

Now, we have bought the MSDOS versions of the Occam and C compilers,
but we'd still like to get/buy a version of isim running on a
DECstation. Is such a thing available (and if so, what's the ordering
information ?).

As an aside, it would be VERY NICE of Inmos if the source for isim were
made publicly available, same as they did with their servers and other
stuff (e.g. the 'check' program). I don't think this would stop people
from buying Transputers!

I guess Inmos people are the most likely to answer my questions.

	Luigi

====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522
====================================================================
Newsgroups: comp.sys.transputer
From: jan@hermes.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: Transputer simulator for SUN
In-reply-to: steved@lion.inmos.co.uk's message of Fri, 2 Oct 1992 09:06:07 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
	<1992Oct2.090607.334@titan.inmos.co.uk>
Date: 2 Oct 92 20:00:40

In article <1992Oct2.090607.334@titan.inmos.co.uk> 
steved@lion.inmos.co.uk (Stephen Doyle) writes:
[lots of good comments deleted]

   > but we'd still like to get/buy a version of isim running on a
   > DECstation. Is such a thing available ...

   NO

Pray, why not? (see below)

   > As an aside, it would be VERY NICE of Inmos if the source for isim were
   > made publicly available, same as they did with their servers and other
   > stuff (e.g. the 'check' program). I don't think this would stop people
   > from buying Transputers!

   If anyone wants to develop a public domain transputer simulator they are 
   quite at liberty to do so. INMOS do not have a policy of giving away 
   valuable intellectual property (especially that containing proprietary 
   information). You have already demonstrated that the availability of isim 
   has had some effect in stopping people from buying transputers.

__FLAME ON__

It is this stupid attitude that over the years has COST Inmos a lot
of sales. Why do you think other manufacturers/OEMS "give away valuable
intellectual property"? Because they know that they have a lot of
potential customers that just don't have the money to buy a sample
of everything just to evaluate a product. Because they know that
just these cashstrapped customers (university departments etc) will act as
multipliers once they get to places where money IS available. Do you
think somebody who probably has the virtual memory on a <insert
favourite workstation> is going to buy 26 transputers with 104MB
just for a test? Sheesh, get real! Are you telling me you can't easily
strip any proprietary information from isim (most of which is probably
widely known anyway, as the PD disassembler from Inmos contains a lot
of undocumented instructions...)?

The same arguments, of course, go for the occam compiler. Thankfully,
things seem to be getting better in recent times, but I just had the
feeling of being back in the dark middle ages!

__FLAME OFF__

Have a nice weekend, guys 'n girls, I'm feeling much better now.
From: ams90@ecs.soton.ac.uk (SHEHAB AM)
Newsgroups: comp.sys.transputer
Subject: Re: Help needed -- cleaning an unsynchronous process
Keywords: transputer inmos c
Date: 1 Oct 92 10:15:13 GMT

In <12964@ecs.soton.ac.uk> ams90@ecs.soton.ac.uk (SHEHAB AM) writes:


>I need to create lots of nearly identical worker processes
>dynamically.  Then once they have executed they return their
>results to their parent processes and should die.  It is when the die
>that my problem starts; how do I get rid of the process from the heap?
>The processes are not started by ProcPar...etc but by ProcRun for
>various reasons.  This means that I can not use ProcAllocClean which
>proved to crash the processors sometimes. I have tried free(process
>pointer) to no avail.

>Any ideas will be greatly appreciated.

Thanks for the resposes I have had from Mark Debbage,Alfred Rizzi, Rob Kurver, Peter Burgess and Andy Pepperdine who have supplied a number of ideas.  The consencus seeams to be an implementation as follows:

1. Pass into every process a channel, a different channel for each process.
Call this channel the "finish-channel".

2. At the end of each asynchronous process, write something to its
finish-channel.

3. When you wish to check whether a process is finished, do a ProcAlt on
its finish-channel. But when the finish-channel is selected, do NOT read
the input on it. Just take the response that it is ready to transfer.

4. At this point, the asynchronous process is known to be locked waiting to
complete an output. If the corresponding input is never performed, the process
cannot continue. So it is at this point that all the process's memory can
be freed. It is not in any execution queue.

5. In order to free all the memory, the processes must not use any default
allocations, so use ProcInit and specify the actual memory area it should
use for the heap.

6. Each asynchronous process must also free all the memory it uses for
its own processing before writing to its finish-channel, ie. put its own
house in order before leaving.

many thanks to Andy Pepperdine for the above steps.

AMS....
Newsgroups: comp.sys.transputer
From: jan@ceres.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: Transputer simulator for SUN
In-reply-to: steved@lion.inmos.co.uk's message of Mon, 5 Oct 1992 09:16:26 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
	<1992Oct2.090607.334@titan.inmos.co.uk>
	<JAN.92Oct2200040@hermes.neuroinformatik.ruhr-uni-bochum.de>
	<1992Oct5.091626.22956@titan.inmos.co.uk>
Date: 5 Oct 92 19:54:06

In article <1992Oct5.091626.22956@titan.inmos.co.uk> steved@lion.inmos.co.uk
(Stephen Doyle) writes:
   There is little interest from our customer base in the DECstation (at least
   in context of other development hosts), for the benefit of our customers we
   focus attention on their preferred host platforms.

Hmmm. So am I to deduce that the company that invented a formally strict
language produces software (presumably, in this case, in C) that is so non
standard that a significant porting effort to the gcc compiler for the DEC
station (and all those other MIPSbased machines from MIPS, SGI, ...) would be
required? And even if so, I'm sure you'd easily find a volunteer to do it for
you (nondisclosure and all). The thing doesn't even have to simulate
the hard part, the FPU!
And don't tell me about quality, manuals etc 
we want this as an addon, not necessarily a supported product.

   Universities do great work at the grass roots level of using and developing
   newer technologies, however, proliferation of a technology is not done by
   Universities but through volume design ins at major OEMs. 

Quite right, but how are these decisions made?

   It would be awfully good for Ford to increase popularity by giving cars to
   University students and commercially selling all their car models for < 10$
   but I don't expect them to commit commecial suicide in doing this.

Nya, get real. We're talking about software, which has low incremental cost.
Why do you think DEC had a 10%oflistprice policy for software for uni
versities, and now has the CSLG?

	Jan
Newsgroups: comp.sys.transputer
From: alf@uni-paderborn.de (Alf Wachsmann)
Subject: Transputer simulator for SUN
Reply-To: alf@uni-paderborn.de
Organization: Uni-GH Paderborn, Germany
Date: Mon, 28 Sep 1992 14:01:58 GMT


Hi,

assumed
1. I have a SUN but no Transputer-Board and
2. I want to compile OCCAM programs for Transputer-Networks and
3. I want to test if the programs are correct

What can I do?

I know that the Inmos OCCAM Toolset has a Compiler which works
without a Transputer, I further know, that in that Toolset there is a
simulator for 1(!!) T425-Board, BUT I want to simulate great
networks so that the memory of one T425-Board is much to small.

So, is there a simulator for great Transputer networks for a SUN?

Any hint is welcome.

Many thanks,
               Alf.




-- 
*     Alf Wachsmann                | Uni/GH Paderborn                  *
*                                  | FB 17 Informatik                  *
*     e-mail: alf@uni-paderborn.de | Warburger Str. 100                *
*     Phone:  +49 5251 60 3312     | D-W-4790 Paderborn                *
*                                  | Germany                           *
From: bane@VTX.MA.MAN.AC.UK (MICHAEL)
Newsgroups: comp.sys.transputer
Subject: OCCAM 3
Date: 2 Oct 92 16:13:57 GMT
Distribution: world
Organization: The Internet

Anybody have progress deadlines for occam-3? Or latest info
on T9 release?

[Are their arrivals interconnected and have they deadlocked?]

Michael Bane
Numerical Analysis and Computing
Manchester University

Tel: 061-275 5800/5825
Newsgroups: comp.sys.transputer
From: steved@lion.inmos.co.uk (Stephen Doyle)
Subject: re: RE: Transputer Simulator for Sun
Reply-To: steved@inmos.co.uk ()
Organization: INMOS Limited, Bristol, UK.
Date: Tue, 6 Oct 1992 10:26:36 GMT

in Article 87 of comp.sys.transputer:
jan@ceres.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes

> ... a significant porting effort to the gcc compiler for the DEC
> station (and all those other MIPSbased machines from MIPS, SGI, ...) would be
> required? 
Porting effort IS significant, we do not throw sources at a compiler and
ship the result, we do something called testing and this means that customers
can rely upon the resulting product. Porting also does not necessarily mean 
rewriting code (which is written in ANSI C) but it does necessitate working
out the difference in functionality between implementations of standard
functions. It is not sufficient to port the simulator, the whole toolset 
would need to be ported. We have learnt to trust gcc, we have had some bad 
experiences with DEC libraries and Posix support.

> And don't tell me about quality, manuals etc 
Plainly quality is not an issue to you, it is to INMOS.

> > ... proliferation of a technology is not done by
> > Universities but through volume design ins at major OEMs. 
> Quite right, but how are these decisions made?
Volume design ins are made due to confidence that the right tools exist
to do the job, that timescales can be met, that the technology to use is the
corporate standard and even sometimes that the technology provides what is
needed. Decisions are made by managers (sometimes not technical) and
buyers, not engineers fresh out of University. 

> Why do you think DEC had a 10%oflistprice policy for software for uni
> versities, and now has the CSLG?
DEC sells big expensive machines to Universities on which to run its
big expensive software. If you were to spend an equivalent amount on
INMOS products you could probably negotiate similar reductions on software.
INMOS is predominantly a silicon vendor and matches pricing, discounts
and functionality of silicon competitors such as Intel and Motorola. We
are not in the workstation market and should not be compared to HP, DEC,
IBM or Sun.

Steve

Steve Doyle, Software Marketing, INMOS Ltd   | Tel +44 454 616616
1000 Aztec West                              | 
Almondsbury                                  | UK: steved@inmos.co.uk
Bristol BS12 4SQ, UK                         | US: steved@inmos.com
From: duplain@rtf.bt.co.uk (Andy Duplain)
Newsgroups: comp.sys.acorn
Subject: Re: sparc file decoder source in C? (for unix)
Date: 29 Sep 92 09:34:13 GMT
Organization: BT Customer Systems, Brighton, UK

In article <Bv96D5.C36@ibmpcug.co.uk> gtoal@ibmpcug.co.uk (Graham Toal) writes:
>I've been given a Sparc archive (stored files only, no compression)
>by someone who couldn't write tar files.  Anyone got any code to
>decode it on unix (I was about to say 'on a sparc' but thought that
>would be too confusing :-) )  Pref. C source.  Or do I have to start
>dumping the files to work out what's in them?

	A !Spark unarchiver for UNIX exists on the Newcastle Info Server,
	and has just been posted to comp.sources.acorn.  I have just
	finished completely rewritting it, and it now supports all archive
	methods used by !Spark 1 and 2 (the original didn't support Squash
	or Compress), CRC checking, MSDOS, and lots more.  It is currently
	in Beta test stage and will be released once all major bugs have
	be squashed.

-- 
Andy Duplain, BT Customer Systems, Brighton, UK.            duplain@rtf.bt.co.uk
#define	DISCLAIMER      My views and opinions are my own, and not my company's
From: dseal@armltd.co.uk (David Seal)
Newsgroups: comp.sys.acorn
Subject: Please use c.s.a.advocacy!
Date: 6 Oct 92 14:22:10 GMT
Distribution: comp
Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK

An appeal to all those involved in the current assembler vs. C debate:
comp.sys.acorn.advocacy was created precisely for arguments like these.
Please take it there!

David Seal
dseal@armltd.co.uk

All opinions are mine only...