Present:        Mick Carter          - UK Met Office

                F E Cox              - Swifte Computer Systems Ltd

                Miles Ellis          - Oxford University

                W Flexner            - Retired

                Mike Geary           - NAG

                Ross de Havilland    - CDC

                Carol Hewlett        - LSE

                Peter Holland        - SS(E)L

                Chris Lazou          - ULCC

                Clive Massey         - SWURCC

                George Mozdzynski    - CDC

                David Muxworthy      - Edinburgh University

                Keith Normington     - Coventry Polytechnic

                Mike Nunn            - CCTA

                T L van Raalte       - MOD

                John Reid            - Harwell

                Angela Smith         - UK Met Office

                J Stratford          - QMC CC

                Alison Wearing       - NCC

                Tony Webster         - Salford University

                Paul White           - UK Met Office

                John Wilson          - Leicester University

                John Young           - MOD (PE)


        Chairman:        John Wilson

                         Computer Centre

                         University of Leicester

                         LEICESTER LE1 7RH

                                  Tel: 0533 554455 ext 9137

        Vice-Chairman:   Keith Normington

                         Computer Centre

                         Coventry (Lanchester) Polytechnic

                         COVENTRY CV1 5FB

        Secretary:       Mike Nunn


                         Riverwalk House

                         157/161 Millbank

                         LONDON SWlP 4RT

        Treasurer:       John Dyke

                         Huntingdon Research Centre

                         HUNTINGDON PEl8 6ES


Apologies were received from Lawrie Schonfelder (Liverpool University).

2.      MINUTES OF PREVIOUS MEETING [17 March 1986]

        2.1. Paragraph 6.2 "depreciated" should be "deprecated".

        2.2. The Chairman expressed his thanks to the Vice-chairman for taking the

        chair in his absence at several recent meetings and to the Secretary for the

        comprehensiveness of the newsletters.


        3.1. The Secretary was drafting a membership application form for newcomers,

        to the Group. It would also be used to collect annual dues (currently £5) from

        non-BCS members.

        3.2. The Group would need to consider framing a request from BCS for an

        increased budget. The Chairman would discuss this with the Treasurer.

        3.3. The Secretary explained that the intended visit to European Weather Centre

        (originally expected for June) had had to be put back to 16 October to fit in

        with availability of accommodation and personnel there. The meeting scheduled

        for Coventry Polytechnic would now take place in December and was hoped to

        include talks on Toolpack, Fortran - C conversion and a NCC demonstration


        3.4. On 30 July there was to be an "open" meeting of the BSI panel at which

        people were welcome to put forward their views on the draft proposed for "8X".

        There would then be a BSI feedback based on the tenor of this into the next

        X3J3 meeting at Halifax, Nova Scotia from August 25-29. X3J3 welcomed views

        from the BCS Fortran Group and also from individuals. The BSI meeting was taking

        place at BSI HQ, 61 Green Street with David Muxworthy (Edinburgh University) as


        3.5. A letter had been received from BCS HQ advising on possible financial

        sponsorship for supported activities and guidelines on how they could be used.

        3.6. BCS Specialist Groups Board had undergone a metamorphosis. There would

        now be a Specialist Group Management Committee reporting to a Technical Board.

        The minutes of the latter were circulated to our Chairman.

        3.7. Documents recently received included:-

                Draft for industrial real-time Fortran;

                Definition of GKS binding.

        3.8. A new Specialist group had just been set up. "PARALLEL PROCESSING

        SPECIALIST GROUP". [Its activities are described in Appendix A]. The

        Fortran Group would add the new Group to our newsletter list. Several of our

        members, including John Reid, would be active in the Parallel Processing Group.

        Its next meeting would be on 25 September at Imperial College consisting of an

        all day Seminar "Languages for ParallelProcessing" chaired by Prof. Perrett

        (Queens University, Belfast).

        3.9. The 10th IFIP world computer congress would be held in Dublin from

        1-5 September 1986.


        4.1. John Reid (Harwell), a regular UK member of X3J3, summarised the main

        happenings of the recent June meeting in New York. It was very important in that

        a compromise was needed in order to get the necessary 2/3 vote in favour before

        the draft "8X" document could be released for public comment. At the previous

        meetings the main areas of contention were:-

                (i) the size of the language; and

                (ii) deprecated features.

        Walt Brainerd, who missed the meeting previous to New York, was very much against

        the new idea of only removing things about 20 years ahead, which he regarded as

        not meaningful in terms of progress.

        4.2. John Reid asked for peoples' views on the new "8X" philosophy. Opinions


                Keith Normington  - it is difficult to understand or remember the nuance

                                    of the difference between deprecated and obsolescent


                Carol Hewlett     - presumably IBM's objections to the size of the

                                    language were because they would have to go on

                                    offering previous compilers as well as "8X" otherwise

                                    if they took things out previous programs would no

                                    longer work.

        4.3. The X3J3 chairman wanted two more editorial meetings and asked whether

        New York attendees would then vote "Yes" for releasing "8X" draft for public

        comment once these editorial changes alone had been made. On a vote there were

        only 4 "Nos" to this.

        Walt Brainerd will produce a new typeset "8X" draft document for the coming

        Nova Scotia meeting. Soon after "8X" goes out for public comment - probably

        late 1986 or early 1987 - the BCS Fortran Group will organise another "Fortran

        Forum" at which it can be presented by X3J3 members and commented on by


        4.4 In New York X3J3 members were asked which features they felt very strongly

        about and would therefore determine whether they would vote "Yes" or "No" for

        public release. The intention was to have an appendix to define certain features

        with explanations that X3J3 had looked at these but decided not to include them.

        This appendix would be included in the public comment document for sure but might

        also be included in the final "8X" Standard document as well. Most of the members

        of our Group tended to feel it was OK for the public comment draft to have an

        appendix of "candidate" features which had eventually been left out but thought

        it inappropriate to put this into a Standard document as well.

        4.5. Possible future timescales (if the next two X3J3 meetings go OK):-

        A 1 year public comment period;

        "8X" just possible to appear in 1988 (but more likely 1989).

        4.6. A glossary of technical terms relating to "8X" will be distributed with

        the draft for public comment. [This is reference "S11"].

        4.7. General views on the "8X" draft release:-

        Miles Ellis            - "8X" was overdue already and it was important to get

                                  the draft out for public comment as soon as possible.

        Keith Normington      - X3J3 was to be congratulated on putting out the draft

                                 with an appendix of considered but rejected features

                                 as an "Aunt Sally" because it would allow them to be

                                 replaced if the consensus of opinion was in favour.

                                 (However Miles Ellis thought such an appendix would

                                 encourage people to say "put them back" with few

                                 saying "leave them out").

        John Reid              - thought IBM will vote "No" and DEC will be willing to


                               - CRAY put forward the compromise; they themselves are

                                 not attracted to having to introduce a large number

                                 of new things into their compilers all at once.

        David Muxworthy        - one could not take IBM's objections seriously; they

                                 just did not want to have to write new compilers.

        4.8. John Reid has as usual kindly provided a detailed report on the New York

        meeting - see Appendix B.


        5.1. David Muxworthy asked about other peoples' experiences with installing

        and using Toolpack. Keith Normington said the accompanying documentation had

        been found inadequate at his own Polytechnic and they had therefore developed

        his own which he was willing to give a copy of to anyone interested. Apparently,

        NAG accepted the documentation was less than perfect. John Reid had found it

        very frustrating trying to put Toolpack up on an IBM system. The trouble was

        one needed to read a 90 page document and go through a pre-processor before

        even starting. Chris Lazou, who had installed it on ULCC Amdahl under MVS,

        offered to help.


In the afternoon George Mozdzynski (Control Data Ltd) gave a talk on the new ETA 10

Supercomputer. A detailed summary appears in appendix C.


The next meeting will take place from 11.00 am to 4.00 pm on 16 October at European

Weather Centre. Details are with attached agenda. All those wishing to attend must

return the enclosed booking form to the Secretary by 29 September.



29 August 1986



A new specialist group is being formed within the British Computer

Society, on Parallel Processing. Our objectives are to promote

the development of parallel architectures, languages and

applications in the U.K.; to act as a focal point for the

dissemination of information about Parallel Processing and to

further commercial benefit to the U.K. for home-based research in

Parallel Processing.

The group will be hosting evening and one-day meetings in its

first year. We are planning at present a one-day review of

commercially available Parallel Processors in the early summer and

a one-day meeting on languages for Parallel Processing in the

early autumn. There will also be a series of early evening talks,

probably initially based in London.

We will be publishing_ an annual Directory of Members and

occasional newsletters. We are also seeking to establish a

central repository for technical material relating to Parallel


Membership is open to all interested parties, membership of the

BCS is not a prerequisite. Student members are also invited at a

reduced rate.

Application Forms are available from the Secretary,

Dr. Nigel D. Tucker

Paradis Consultants

East Berriow

Berriow Bridge,

North Hill,

Nr. Launceston,

Cornwall, PLl5 7NL


To:             BCS, NAG, etc.

From:           John Reid

Date:           21 June 1986

Subject:        Report on X3J3 meeting at Mount Kisco, New York

Note:           This is a personal report of the meeting and in no sense

                does it constitute an official record of it.

References:     [1] 100(*)KH-1 Deprecated features proposal

                [2] 100(*)WSB-2 The Decline of Western Civilization

                [3] 100.JLW-2 Fortran 8x/99

                [4] 100(l3)JKR-2 S8 Glossary of technical terms

                [5] 100(l9)JKR-3 Taming REAL(*,*).

1.      Summary

        This was a critical meeting. There was a real possibility of

reaching deadlock on the overall content of Fortran 8x, with more than

a third of the members unwilling to vote the standard out for public

comment either because it was too large or because too many wanted

features had been removed. Also the near-unanimity at the April

meeting in Scranton on the changes to the deprecated features had been

lost. However, the changes to the deprecated features were passed

(see section 2) and a proposal on reducing the size of the language

(see section 4) was accepted after some significant changes. A first

cut at the set of changes needed to the document was accepted and it

is the Chairman's aim that two more meetings (in August and November)

devoted to editorial changes will produce a document that at least

two-thirds of the committee accept for release for public comment.

When asked how they expected to vote in November, 22 members said

'yes' and 4 said 'no'. It will be tough to get the document into

shape by then, but at least the committee appears to have avoided the

possibility of deadlock on the technical content.

        Other actions taken during the week included minor editorial

changes, resolution of the REAL(*,*) problem (see section 5),

discussion of storage mapping (see section 3), discussion of data

initialization (see section 6), adoption of a glossary (see section 7)

and adoption of some changes in the i/o area (see section 8). The

committee was addressed by two Fortran 77 compiler writers, Tom Lahey

and Stu Feldman, both of whom argued for a reduction in the size of

the language. Tom was critical of the quality of the current

document, did not like so many intrinsics being accessible at compile

time, and wanted hooks to other languages. Stu was critical of

dependent compilation and wanted the underlying model to be explained


2.      Obsolete, obsolescent, and deprecated features

        The committee adopted (l7-11) a formal proposal [1] to split the

deprecated features into two categories. Those to be called

'obsolescent' have replacements in Fortran 77 and may be removed from

Fortran 9y if their use has become insignificant. The rest continue

to be called 'deprecated' and may be moved to the obsolescent list in

Fortran 9y for possible removal from Fortran 102. At the April

meeting in Scranton, the change was regarded as satisfactory by all

members except one. However, Walt Brainerd, who was not at Scranton,

meanwhile made a strong plea [2] for leaving the deprecated features

alone. He wants to permit a faster evolution of the language. A few

of the members that were at Scranton changed their votes and a few not

at Scranton voted against it with Walt Brainerd, which is why it did

not achieve the near-unanimity that it had at Scranton. Later in the

week, the committee considered dropping the idea of obsolescence and

deprecation altogether or keeping only obsolescence. It rejected both

changes overwhelmingly (4-18-2, l-20-4). I would have been very

unhappy with either of these changes because I think we need an

evolutionary path.

        Later it was decided to add an empty list of 'obsolete' features

to be removed from Fortran 77 and to modify the obsolescent list to

the following: arithmetic IF, real and double precision DO control

variables, loop termination other than on a CONTINUE or END DO

statement, terminating more than one DO loop on a single statement,

branching to an END IF statement from outside its IF block, alternate

RETURN, PAUSE, and ASSIGN and assigned GOTO. The last three are

additions to the tentative list established at Scranton.

3.      Storage association

        For several years the committee has been working with the

assumption that COMON, EQUIVALENCE, and all forms of storage

association are deprecated because of the portability problems they

bring. This assumption was challenged during the discussions at

Scranton and Mike Metcalf was asked to look into alternatives for the

bit-mapping capabilities of storage association. The committee

preferred the idea of adding some bit-mapping intrinsics (possibly

subroutines), but snags were found in Mike's proposal. He will bring

a fresh one to the next meeting. A formal vote on removing storage

association from the deprecated list failed (11-l5).

4.      Size of the language

        A major attempt was made at Scranton to find a compromise

position on the contents of Fortran 8x that all or most of the

committee could accept. This was summarized in my last trip report

and in a paper [3] written by Jerry Wagener. Some major variations

were explored early in the Mount Kisco meeting, but the proposal that

was eventually accepted (25-4) was a relatively minor variation. The

changes were the following:

(1)     Not to move to the appendix:

        (a) user-defined operators

        (b) array constructors

        (c) RANGE.

(2)     To move to the appendix

        (a) BIT type

        (b) variant structures.

(3)     Not to add pointers to the appendix.

(4)     To reduce storage mapping to a bit-transfer capability.

(5)     To unify IDENTIFY with RANGE.

(6)     Not to separate the two forms of DO.

        There was some sentiment for the appendix becoming an addendum

to the draft standard, but removed from the final version. This would

mean that the features in the appendix were quite clearly not a part

of the standard. It would also mean that they were less visible to

implementors designing extensions. The committee chose to stay with a

conventional appendix (l4-8-7).

        Keeping user-defined operators but not operator overloading

represents a compromise that I am willing to accept. We have, after

all, lived a long time spelling '<' as '.LT.'. One or two members

were concerned at the lack of safety involved in operator overloading

- the user may not get the result that he or she expects. I was also

happy to see pointers not being included in the appendix, because they

would represent a major addition that would substantially delay the

release of the draft for public comment.

        There was concern about the loss of facilities for skew arrays,

and I believe that item (5) was intended to address this loss. George

Paul presented some ideas, but they seemed to offer little

simplification over the present form of IDENTIFY and exposed differing

views on what item (5) implies. In a private discussion after the

meeting, George Paul, Alan Wilson, and I explored the removal of all

alias and many-to-one properties from the IDENTIFY statement. This

idea looks hopeful, but has no official status.

        I was pleased to see the abandonment of the separation of the

two forms of DO. The problems have more to do with the formal

description of the facility than any genuine difficulties.

        The proposal passed involves the following:

  1.    Move to appendix:

        (a) treating arrays of arrays as higher-rank arrays

        (b) CONDITION and ENABLE

        (c) operator overloading

        (d) structure constructors

        (e) the intrinsic functions DIAGONAL, RANK, REPLICATE,


        (f) nesting internal procedures

        (g) passing internal procedures as actual arguments

        (h) FORALL

        (i) IDENTIFY/ALIAS

        (j) vector-valued subscripts

        (k) variant structures

        (l) BIT type

  2.    Simplify internal procedures, modules, and USE.

  3.    Add bit-transfer capability.

  4.    Remove significant blanks and insignificant underscores.

  5.    Replace name-directed i/o with NAMELIST.

  6.    Unify IDENTIFY with RANGE.

5.      Real(*, *) combinatorial explosion

        My proposal [5] to limit the number of versions of a procedure

having dummy arguments with passed-on precision to the number of

native precisions on the computer was accepted (23-1). It limits the

number of such arguments to one and allows others to have their

precisions linked to it. It was criticized for the clumsy notation as

exemplified by


        REAL(6) A(100)


        CALL DOT(A,B,C)



        REAL(*) A(:)


If the calling procedure is changed so that B and C are declared with

precision 6, the program will conform to the standard only on

processors having a representation with effective precision 6. Some

people felt that the argument conformance rules should be relaxed to

require conformance only of effective precision, but then conformance

would still sometimes be processor dependent. Carl Burch is looking

at the problem.

6.        Data initialisation

        Ivor Philips suggested several possible simplifications or

combinations of the INITIAL attribute and the DATA and INITIALIZE

statements. The committee favoured spelling them all DATA and

extending the INITIALIZE statement to include the implied DO construct

applied to arrays and array sections.

7.        Glossary of technical terms

        I proposed a glossary [4] of technical terms for an appendix to

the draft standard. It was welcomed, apart from a few terms whose

meaning altered with the change to the meaning of deprecation.

Several people were concerned about possible inconsistencies between

it and the main text, so it was agreed that the glossary should be a

new standing document (S11) rather than an appendix. It was adopted

(20-1), and I was asked to revise it to reflect proposals passed at

the meeting.

        We also had a discussion about some terms that are currently

used with inconsistent meanings in different parts of S8. We agreed

that 'array' is a generic term that includes, for example, array

sections; and that 'constant' is a generic term that includes literal

and symbolic constants; we decided to use 'named' in place of

'symbolic' and to use 'designator' for a string representing an array


        Earlier in the week it was agreed (l9-2-6) that the

simplifications to modules and internal procedures lead to our having

three kinds of procedures: an internal procedure is one whose

definition lies inside another procedure, a module procedure is one

directly hosted by a module, and an external procedure is one that is

not contained in a module or another procedure.

8.        Changes in i/o area

        Lloyd Campbell voted 'no' in his ballot because the default for

a formatted read that goes beyond the end of a record is not to pad

with blanks, but to regard this as an error. Many existing

implementations automatically pad with blanks. In Fortran 8x, this

effect can be obtained with the specifier PAD='YES', but it is not the

default. A proposal to remove the PAD= specifier and always pad with

blanks failed(11-12). Several people felt that it should be possible

to run in a mode that regards this situation as erroneous. The

proposal to change the default to PAD='YES' passed (16-5).

        In response to requests from the ISO group in Bonn, Carl Burch

proposed adding the RECL= specifier to OPEN and INQUIRE statements for

sequential files, to return the maximal record length that can be read

from or written to the file. This passed (l7-0). Unfortunately it

does not address the problem that I believe the Bonn people had in

mind, which is to provide a facility to find out how long the next

record is. Carl has a simple proposal for this, which he intends to

bring to the committee.

9.        Next_meeting_of X3J3

        The next meeting will be in Halifax, Nova Scotia, Canada,

August 25-29. The premeeting distribution deadline is July 21.


THE NEW ETA SUPERCOMPUTER - Talk by George Mozdzynski (Control Data Ltd)


ETA Systems is a company set up by CDC in 1983 with an objective to design and

develop the fastest and most reliable supercomputer in the world. Located in

St Paul (twin city of Minneapolis) ETA Systems can be regarded asa separate company

from CDC in some respects although CDC owns 89% of the share equity. The ETA 10

supercomputer that has been developed is marketed by ETA Systems in the USA but by

Control Data Ltd in the UK.


A good definition of a supercomputer would be a computer that is one of the very

fastest at any point in time. ETA Systems was set up with the strict goal of developing

the fastest machine of all and that it must be available in the field within three

years. That objective has been achieved with the machine now operational and the first

delivery soon to take place.


Three customers have already signed contracts to buy the ETA 10. The first system

comprising a 4-processor model will be delivered soon to Florida State University.

ETA 10 is a multi-processor computer incorporating up to 8 cpus. The first three

systems delivered will be 4, 4 and 8 processor configurations. The first prototype

code name Cygnet (with 1 cpu) was turned on at the ETA laboratory in St Paul on

29 May. It only took 5 days to run diagnostics, a vast improvement compared with the

Cyber 205 where 9 months were needed to complete diagnostic runs. The speed-up is

due to the technology employed. The operating system is being checked out over the

period July-September 1986 and at the same time the Florida State machine is being

built. It should be delivered in November or December.


ETA 10 design target was originally for a 7 nsec clock cycle time. This has not yet

been achieved because of problems with getting sufficient yield of chips of the

right quality. So the initial machine will be delivered with a 10.5 nsec clock.

But by July 1987, ETA Systems expect to have a 7 nsec clock machine available. By

extending the same technology clockspeed will be down to 5 nsec in 1988 and larger

memories will also be available.


The cpu is just 22" x 16" comprised of a single printed circuit board with 240 chips.

This is interesting to compare with the Cyber 205 which, although offering processing

power of only one third of one ETA processor, occupies space the size of a medium

size room. Shared memory between the ETA processors is comprised of 256 K chips with

a 1 megaword memory module occupying just a 4 inch cube. ETA 10 can run at normal air

temperature, but runs twice as fast at -194°C using liquid nitrogen cooling. It is

the first system to use this type of cooling.


A system can comprise between 1-8 cpus, all having both a scalar and 2-pipeline vector

processor. Each cpu has its own 4 million 64-bit words of memory. There is also

between 32 and 256 million words of shared memory between the cpus. A system supports

between 2 and 18 I/O units - so in theory one could have up to 1,000 disk drives

attached. Magnetic tapes and networking are also supported.

Benchmark Performance

Using Argonne Laboratory's Linpack benchmark a single processor ETA 10 has been

measured using a simulator at 195 megaflops. (Peak performance of a single

processor ETA 10 is 570 megaflops). A CDC benchmark showed it as 3.5 x the power

of a Cyber 205. By comparison with rival supercomputers ETA 10 and Cyber 205 have

the advantage that they can use both 32 and 64-bit arithmetic.


ETA 10 will operate under either VSOS (the Cyber 205 operating environment) or Unix

(AT&T System V.2). Programming languages supported are Fortran, C and Pascal. A

multi-tasking library is provided to allow user applications to make use of the

multi-processor facility in an ETA 10 configuration.

Supercomputer Performance Issues

Delays in logic circuits can be due to:-

        (i) gate delays         - a function of the material and depend on the speed

                                  of electrons through it;

        (ii) propagation delays - depend on distance and signal propagation speed.

ETA Systems decided to use CMOS rather than Ga As because it allows thousands of

devices on a single chip whereas Ga As only permits a hundred or so. And if you cannot

get enough logic onto one chip you inevitably encounter communication delay in

connecting to other chips. [Relative delay times would be chipl , PC board 10,

coax 30]. By 1990 CMOS technology will have advanced to 100 k gates/chip so it will be

possible to build a cpu with just 40 chips.

Ga As is in fact of two types:-

        "depletion mode";       and

        "high energy molecular technology" (HEMT).

The latter will be available in the 1990s. HEMT more resembles CMOS than depletion

mode, eg it offers the same number of gates per chip. ETA Systems has the choice in

the future of moving to Ga As or staying with CMOS.

ETA 10 Technology

The cpu comprises a single 42-layer printed circuit board containing 250 CMOS chips

each with approximately 20,000 logic gates. Each chip has self-test diagnostics,

which accounts for how ETA Systems could check out the whole machine in 5 days. Each

chip has about 280 pins.

The cpu is immersed in liquid nitrogen at -194°C. As the liquid warms it turns to

gas and is fed round the cryogenic unit. Power used by the cpu is only 700 watts

(about 20-30 times less than the Cyber 205). The machine can plug into a normal

wall socket. The cryogenic generator however needs quite a lot of power so that total

system requirement is 160 KVA (but still only 25% of the Cyber 205).

Cpu memory is 4M word of 64 K static MOS RAM. Memory addressing logic supports

64 M words ( 64 M word cpu memory will be available by 1988). Shared memory between

the cpus consists of between 64-256 words of dynamic MOS RAM. Bandwidth between cpus

and shared memory is very high (9.1 G bits/sec). Instruction set is compatible with

Cyber 205 but includes extra ones as well.

A system can support up to 18 I/O units which enable attachment of disks, magnetic

tape units and networks. Between the I/O units and shared memory transfer rates can

be sustained at UUOM bits/sec. Device capacity for each physical disk is 600 M bytes

or 1.25 G bytes. Burst transfer rates are 12 M bytes/sec and sustained transfer rates

10 M bytes/sec. All data communication between processors is via shared memory and

processor can also share information via a communication buffer. Shared memory serves

the purpose of both acting like a CRAY solid state device (SSD) and as a paging device.

Each cpu has one scalar and a 2-pipeline vector processor. This combination was

chosen because, unlike a 1 scalar/4-pipeline mix, it could be implemented on a single

board and also offered a better balance. Both 32-bit and 64-bit arithmetic working

is possible. Each user can view the ETA 10 hierarchical memory as one large virtual

address space.

Flexible scheduling options allow the multiple processors of the ETA 10 to be either

applied in parallel to provide high performance to a single application process or

to be applied individually to sets of jobs and so provide high system throughput.


The ETA 10 offers two types of networking:-

        (i) LCN      - existing CDC network with bandwidth up to 50 M bits/sec;

                     - consists of a variety of network access devices (NADs)

                       interconnected by coax using proprietary transmission

                       mechanisms and protocols, eg allows connection to IBM and DEC;

       (ii) TCP/IP   - Ethernet trunks (IEEE 802.3 based) each supporting 256


                     - TCP/IP is the DOD protocol allowing connection of variety

                       of devices to Ethernet and ETA 10;

                     - allows direct connection of terminals to ETA 10 (a big

                       advance compared with Cyber 205).

Software - Operating System Environment

Two operating systems are available:-

        (i) UNIX        - AT&T System V.2 with Berkeley extensions;

        (ii) VSOS       - offering compatibility with existing Cyber 205 sites.

ETA Systems believe that most interactive access will be via Unix. They are also

looking at offering a NOS/VE environment as well.


Two Fortran implementations are offered:-

        (i)  FTN 200    - this is Cyber 205 F77 and is offered for compatibility;

                        - automatic vectorising could be better;

       (ii)  Peritus International are developing the ETA Fortran compiler. It will

             be the first one able to vectorise all the Livermore loops. Array

             extensions anticipated for "Fortran 8X" have been built in. Other

             features incorporated are Cyber 205 vector notation and common vendor

             extensions, eg IBM type declarations. ETA Systems believes the compiler

             also offers good scalar optimisation. Pacific Sierra are developing an

             automatic Fortran vectoriser for ETA 10 based on their VAST product.

             Initially automatic vectorisation will be achieved (as VAST does at

             present) by running a program through the compiler via a batch-type

             interface. But fairly soon there will be an interactive vectoriser which

             will prompt the user on paths and vectorisable constructs associated with

             achieving high optimisation. Other goodies offered will be a symbolic

             debugger and post-mortem dump with traceback (not available on Cyber 205).


ETA Systems strategy for multi-tasking is via calls inserted by the user into his

Fortran source code. Although some automatic partitioning ("microtasking") is available

it is more difficult to achieve speed up at multi-tasking comparable with that achieved

by vectorisation. In fact as Fortran is not a language suited to multi-tasking ETA

Systems is interested in providing an outer layer on top of Fortran to provide this. A

multi-processor interactive debugger will be offered. The multi-tasking library

allows a program to be written in any language eg C, Pascal and use this library.


A simulator for multi-processing the ETA 10 which runs on the Cyber 205 has produced

the following results:-

        Application                     Number of ETA 10         Speed up

                                        Processors in            Compared with

                                        Configuration            Single ETA 10 Processor

        Matrix multiplication                2                      2.0

        (1000 x 1000)                        4                      3.9

                                             6                      5.9

                                             8                      7.8

        Matrix transpose                     8                      7.0

        (4000 x 4000)

        Gaussian elimination                 4                      3.2

[NB: Overheads of multi-tasking have been included in the simulator].


Two series of machines are to be announced:-

        1. 'E' Series (with 10.5 nsec clock)

        Performance          0.8-3.2 G flops

        Cpus                 1-4

        Shared memory        32-128 M words

        Pricing             £3.6 M - £8 M

        The first three systems delivered to the Universities of Florida State,

        Minnesota and Pittsburgh will be 'E' Series.

        2. 'G' Series (with 7 nsec clock)

        Performance          4.6-9.2 G flops

        Cpus                 4-8

        Shared memory        128-256 M words

        Pricing             £8.6 M - £14.6 M

        'G' Series machines are scheduled to be available in July 1987.

Logic chips being developed by Honeywell for ETA 10 are valued at $2,600 so a single

cpu contains chips worth $0.5 M.

Serviceability/System Redundancy

ETA 10 was designed to offer full redundancy so that if any part fails the system

will still operate. MTBF for an individual cpu should be about 1 year. It will be

possible to replace a cpu within 3 hours even though the liquid nitrogen coolant

needs to be cycled up and down from its 77°K operational temperature to allow the

replacement to take place. It should be noted that liquid nitrogen is a far more

reliable medium than air.


George Mozdzynski says that main competition is likely to come from CRAY but that the

ETA 10 outperforms both CRAY X-MP and CRAY 2 and also offers at least a 2:1 price

performance advantage in comparison with them. One could only guess at performance,

price, timescales etc of CRAY Y-MP (1987?) and CRAY 3 (1988?).


Key benefits of ETA 10 are:-

     1.  Better price/performance than today's competition.

     2.  Reliability because of  - built in redundancy;

                                 - environment cpu runs in;

                                 - high density 20 K gate chips with few

                                   connections [connections are trouble];

                                 - MTBF for cpu of 1 year.

     3.  Can operate with or without front-end system.

     4.  Upgradeability  - easy to add in further opus to configuration

                           (and without even needing to bring system down).

     5.  Maintenance     - very little preventative maintenance needed and not

                           necessary to have engineer on site.

     6.  Enhancement     - compatible successor products will be offered using

                           technology such as HEMT.