Admired designs / designs to study
Mark Smotherman
>If you want traffic: generate some.
#1 - admired designs
It's been five years since I asked a group of computer
architects about the designs that they admired:
http://www.cs.clemson.edu/~mark/admired_designs.html
The list of admired designs is:
6502
CDC-6600 and 7600
Cray-1, -2, -4
Cray X-MP and Cray Y-MP
GE-645 (Multics)
IAS
IBM Stretch
IBM 1401
IBM 1570 (not marketed)
IBM 7040 and 7090
IBM S/360 and S/370
IBM S/360 Model 91
IBM ACS
IBM America (RS/6000)
Intel x86
LC-2
MIPS
Multiflow
PDP-11
and a list of some designs which might serve as a source
of counterexamples is:
CDC-8600
IBM Stretch (on both lists)
NS-32016 (16032)
VAX-11
Nominate some other designs for either list and explain
why. E.g., the Intel 432 is often a source of counter-
examples for instruction set design weaknesses (e.g.,
bit-aligned instruction formats and no literal fields)
as well as microarchitectural weaknesses (e.g., lack of
access descriptor cache). Bob Colwell did an excellent
post-mortem analysis of the 432 years ago.
With regard to newer designs, on which list would you
place, for instance, the DEC Alpha and why? IBM/Sony/
Toshiba Cell? Itanium? SPARC T1? TI C67x? Transmeta?
#2 - computer system papers to study
In a similar vein of thought, if we were going to put
together a Computer Structures book in the format of
the classic Bell and Newell book, and the Siewiorek,
Bell, and Newell book, which papers about specific
computer system designs would we choose and why?
on-line copy of Bell and Newell
http://research.microsoft.com/users/GBell/Computer_Structures__Readings_and_Examples/index.html
on-line copy of Siewiorek, Bell, and Newell
http://research.microsoft.com/users/GBell/Computer_Structures_Principles_and_Examples/index.htm
E.g., I would nominate
Bob Rau, et al., "The Cydra 5 Departmental Supercomputer:
Design Philosophies, Decisions, and Trade-Offs," IEEE
Computer, January 1989 (Vol. 22, No. 1), pp. 12-26,
28-30, 32-35.
because of the Cydra's impact on the Intel Itanium
(predication, rotating registers, etc.). Also, I think
the HARP VLIW design by Gordon Steven and others in
England would be an important design to consider for
inclusion because its instruction format and design
decisions.
G.B. Steven, et al., "HARP: A Parallel Pipelined RISC
Processor;" Microprocessors and Microsystems, November
1989 (Vol. 13, No. 9), pp. 579-587.
Terje Mathisen
Admired:
PentiumPro
ARM
Alpha
> With regard to newer designs, on which list would you
> place, for instance, the DEC Alpha and why? IBM/Sony/
> Toshiba Cell? Itanium? SPARC T1? TI C67x? Transmeta?
Counterexample:
Itanium (Just too complicated, unfortunately. :-()
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
John Mashey
Mark Smotherman wrote:
> Nominate some other designs for either list and explain
> why. E.g., the Intel 432 is often a source of counter-
With one exception, my favorites [S/360, CDC 6600, Cray, and of course
MIPS :-)] are well-represented on others' admired lists:
Burrough B5000/B5500.
I always thought it was one of the most innovative examples of combined
hardware/software design I've seen, and far ahead of its time.
Introduced in *1961*:
1) No assembler, OS (MCP) written in ESPOL (an Algol variant).
2) Efficient support for Algol, including call-by-name (!!), also COBOL
& FORTRAN
3) Multiprocessor.
4) Virtual memory (via segmentation)
http://en.wikipedia.org/wiki/Burroughs_B5000 is pretty good discussion.
The descendents of these are *still* being shipped (under Unisys
ClearPath name).
I think that the 1961 introduction date makes this the *oldest*
general-purpose computer architecture whose direct descendents are
still being shipped (I think the Sperry Univac 1107, introduced in
1962, is the next oldest, followed by the S/360). To be fair, the
architecture changed somewhat in going from B5500 to B6500, so maybe
that oldest honor belongs to the Unisys 1100/2200/ClearPath series,
also being shipped.
(Clearpath label includes both mainframe series).
http://en.wikipedia.org/wiki/UNIVAC_1100/2200_series
One would *not* design a B5000-like ISA today, or even in last 20
years:
a) Stack- and tag-oriented CPUs take more work to pipeline well.
b) Compiler technology has moved.
c) Doing Algol call-by-name in hardware isn't the way the industry
went.
d) And of course, machines with 48 or 51-bit words, on which C fits
poorly, don't happen now...
Nevertheless, at the time, this was an exceptionally forward-looking
design.
Tommy Thorn
> Counterexample:
> Itanium (Just too complicated, unfortunately. :-()
In the early years I was really afraid that Intel would succeed in
locking the market into their proprietary VLIW, but now that it's all
but completely dead I can admit that I really like the floating point
model. Other features individually looks nice, but the whole is a
kitchen sink designed by committee.
Tommy
jacko
if i had to pick one to run the desert island it would be 68EC000
(amiga)
Tim McCaffrey
says...
>
>eug...@cse.ucsc.edu (Eugene Miya) writes:
>>If you want traffic: generate some.
>
>
>#1 - admired designs
>
>
>It's been five years since I asked a group of computer
>architects about the designs that they admired:
>
Admired:
Moto 68000 (compared to what else was out there, it was
great).
Moto 6809 (neat little architecture, if a bit limited here
and there)
RCA 1802 (Ok, I like it because it was so different).
MIPS 64 bit (Some rough edges, but pretty nice)
Not Admired:
Signetics 2650 - This seems like a prime example on how to take
every architectural kludge up to that point in
time and put them in one chip. Yech.
Chris Quayle
>
> The list of admired designs is:
>
> 6502
> CDC-6600 and 7600
> Cray-1, -2, -4
> Cray X-MP and Cray Y-MP
> GE-645 (Multics)
> IAS
> IBM Stretch
> IBM 1401
> IBM 1570 (not marketed)
> IBM 7040 and 7090
> IBM S/360 and S/370
> IBM S/360 Model 91
> IBM ACS
> IBM America (RS/6000)
> Intel x86
> LC-2
> MIPS
> Multiflow
> PDP-11
>
Wot, no 68K ?. More than any other, it was the architecture that broke
the mini market and put affordable unix onto the desktop.
For embedded, the TI msp430 would be good candidate...
Chris
--
Greenfield Designs Ltd
-----------------------------------------------------------
Embedded Systems & Electronics: Research Design Development
Oxford. England. (44) 1865 750 681
Eliot Miranda
Xerox Alto. First true bitmapped workstation. Innovative microcode
architecture (16 microcode tasks). Ethernet. Removable disc drive.
Smalltalk. See C. P. Thacker, E. M. McCreight, B. W. Lampson, R. F.
Sproull, and D. R. Boggs. "Alto: A Personal Computer." D. Siewiorek, C.
G. Bell, and A. Newell, Computer Structures Readings and Examples,
editors, second edition, McGraw-Hill, 1979.
--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd
Eliot Miranda
Eliot Miranda wrote:
[snip]
uh, never mind. Alto makes the "secondary machines" list. Rather
condescending for such an innovative system.
> Xerox Alto. First true bitmapped workstation. Innovative microcode
> architecture (16 microcode tasks). Ethernet. Removable disc drive.
> Smalltalk. See C. P. Thacker, E. M. McCreight, B. W. Lampson, R. F.
> Sproull, and D. R. Boggs. "Alto: A Personal Computer." D. Siewiorek, C.
> G. Bell, and A. Newell, Computer Structures Readings and Examples,
> editors, second edition, McGraw-Hill, 1979.
--
Eugene Miya
>>If you want traffic: generate some.
In article <ebt230$1si$1...@hubcap.clemson.edu>,
Mark Smotherman <ma...@clemson.edu> wrote:
>#1 - admired designs
Mark: a nice start. Edited the subject line, minimized attribution.
Clean Reference line.
>It's been five years
> http://www.cs.clemson.edu/~mark/admired_designs.html
>The list of admired designs is:
I'll trim for my comment.
> CDC-6600 and 7600
> Cray-1, -2, -4
> Cray X-MP and Cray Y-MP
> GE-645 (Multics)
Hmmm, not the Cray 3. Makes me wonder what you learned about the Cray 4
(got it, maybe you might consider a plane flt to the Bay Area about
Sept. 21). The Multicians are going to make to make due with a Honeywell
machine. I lost the 1 645 I got for surplus while I was at JPL.
> IBM Stretch
> IBM 1401
> IBM 7040 and 7090
> IBM ACS
Well the ACS for me is a different headache.
> Intel x86
> Multiflow
Saved one for Josh.
Also got a Cydra 5, but I'm missing a slew like the SCS-40 and 30.
>and a list of some designs which might serve as a source
>of counterexamples is:
> CDC-8600
Interesting choice.
Some of that may be more on running a business than technical reasons.
> IBM Stretch (on both lists)
> NS-32016 (16032)
> VAX-11
I like the duality of 7030 you put here, shows you are a man of quality
(and that life is full of hard choices).
>E.g., the Intel 432 is often a source of counter-examples
>...Bob Colwell did an excellent
>post-mortem analysis of the 432 years ago.
I think adjunct comments like this are good.
>Transmeta?
Gotta troll for Dave on this one.
>#2 - computer system papers to study
>
>In a similar vein of thought, if we were going to put
>together a Computer Structures book in the format of
>the classic Bell and Newell book, and the Siewiorek,
>Bell, and Newell book, which papers about specific
>computer system designs would we choose and why?
>
> on-line copy of Siewiorek, Bell, and Newell
> http://research.microsoft.com/users/GBell/Computer_Structures_Principles_and_Examples/index.htm
To a certain degree, you can point to top ten lists.
But you need more than papers themselves like commentary and annotation.
>E.g., I would nominate
> Bob Rau, et al., "The Cydra 5 Departmental Supercomputer:
>because of the Cydra's impact on the Intel Itanium
>(predication, rotating registers, etc.).
A good choice.
>Also, I think
>the HARP VLIW design by Gordon Steven and others in
>England would be an important design to consider for
>inclusion because its instruction format and design
>decisions.
> G.B. Steven, et al., "HARP: A Parallel Pipelined RISC
> Processor;" Microprocessors and Microsystems, November
> 1989 (Vol. 13, No. 9), pp. 579-587.
I added it to my biblio.
Value added.
Others will comment, how will you summarize?
The long term is what not only this thread means to comp.arch and Usenet,
but how it's maintained beyond this time and not mere archiving.
--
Eugene Miya
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>"almost all programming can be viewed as an exercise in caching"
So Terje, you guys still producing heavy water?
--
Eugene Miya
Tim McCaffrey <t...@spamfilter.asns.tr.unisys.com> wrote:
>MIPS 64 bit (Some rough edges, but pretty nice)
Yeah I go along with this as well as the ECL MIPS 6000.
We trolled John to join the thread. I think we need more than mere CMOS.
Mark, you might back check a similar thread in alt.folklore.computers.
--
Mark Smotherman
>I like the duality of 7030 you put here, shows you are a man of quality
>(and that life is full of hard choices).
It wasn't clear in my original post - the list and entries should
be credited to folks like Don Alpert, Bob Colwell, Josh Fisher, etc.,
who were kind enough to respond to me and grant permission to post
their comments on the web page:
http://www.cs.clemson.edu/~mark/admired_designs.html
And so the discussion of and placement of Stretch on both lists
should be credited to Dick Sites.
[I did recently update my own discussion on Stretch using Harwood
Kolsky's documents from the Computer History Museum:
http://www.cs.clemson.edu/~mark/stretch.html
-- the Stretch lookahead owes more to Gene Amdahl than I had ever
realized.]
John L
>>
>> NS-32016 (16032)
What was wrong with the design of the 32016? I realize the
implementations didn't work, but the architecture was a pretty
straightforward knockoff of the -11.
R's,
John
John Mashey
Well, it's rather more complex than a PDP-11, somewhat more VAXish.
1) Implementation counts: an ISA may be clean, elegant, powerful, etc
...
But, unlesss it's a research machine, it must be possible to implement
a competitive sequence of CPUs, across several generations, or it dies.
2) It may be that a good ISA could have been well-implemented, but
didn't,
3) Or it may be that it was intrinsically harder to implement than one
expected.
3) I don't know which of 2) or 3) contributed to the demise of the
NS32xxx; it was certainly the case that many system designers of the
time liked the ISA (I did, even though I knew 68Ks better), but most of
those who bet on it got burnt, in comparison with the less elegant 68K,
for which reasonable implementations appeared.
4) Of course, if one goes back to my old comp.arch large RISC vs CISC
table, the 32016 (labeled "N1") came out close to a 68040, and would
have suffered similar performance issues in trying to make it stay
competitive, given indirect addressing, multiple memory operands almost
anywhere, etc.
Terje Mathisen
As of quite few years ago, when my father was the director of Hydro's
Rjukan facility, we did indeed still make heavy water.
However, afaik this production was tied to the manufacturing of rare
gases, and that part of Hydro (mainly the original fertilizer
facilities) has been fissioned out into a separate company, called Yara.
(Yara kept our traditional viking ship logo as well, since fertilizer
sales in many parts of the world was believed to be more tightly
connected to the logo than to the name.)
http://www.yara.com does not tell me it they still make it. :-(
Terje
--
- <Terje.M...@hda.hydro.com>
Jan Vorbrüggen
>>
>> 6502
>> CDC-6600 and 7600
>> Cray-1, -2, -4
>> Cray X-MP and Cray Y-MP
>> GE-645 (Multics)
>> IAS
>> IBM Stretch
>> IBM 1401
>> IBM 1570 (not marketed)
>> IBM 7040 and 7090
>> IBM S/360 and S/370
>> IBM S/360 Model 91
>> IBM ACS
>> IBM America (RS/6000)
>> Intel x86
>> LC-2
>> MIPS
>> Multiflow
>> PDP-11
From my point of view, add the early transputers, in particular the
T800. All you need on one chip: processor, memory, network interface,
OS 8-).
OTOH, the T9000 is split: the VCP (virtual channel processor) I admire,
the rest is more of a counter-example, in no small part due to bad
implementation.
Jan
Peter Grandi
>>> Miya) said:
[ ... ]
eugene> Yeah I go along with this as well as the ECL MIPS 6000.
eugene> We trolled John to join the thread. I think we need
eugene> more than mere CMOS. [ ... ]
I nominate the Manchester MU4/Atlas and MU5 (and perhaps the MU6
successor). They were important, well designed architectures
that went on to considerable commercial success in one form or
another (the MU4 as itself, the MU5 as the ICL 2900 series).
They both had some interesting first, e.g. MU4 for virtual
memory, MU5 for a LAN distributed heterogenous OS.
The CPU architecture of both was in the usual and very effective
Manchester style of specialized registers/accumulators (which in
part inspired my idea of a 4-stack CPU).
Disclaimer: I was briefly involved (a few months) with MU CS,
and perhaps I was a bit too awed by how nice and interesting the
people and their work were at MU CS.
There are several paper on both, with several bibliographic
entries here:
http://WWW.sabi.co.UK/Notes/csGreatObs.html
and a collection of materials, including photos etc. around
http://WWW.Computer50.org/kgill/
As to books, some architecture books by Manchester people are
pretty good, for example the MU5 related "The MU5 computer
system" by Morris and Ibbett (MacMillan 1980) and the more
general "The architecture of high-performance computers" by
Ibbett and Topham (MacMillan 1989) which is a little known
classic.
These were probably the last ''big iron''/research computer
designs made in Europe. Manchester went on to do some work on
dataflow and OO architectures, and Cambridge on capability
systems and token ring, but they were not on the same scale.
In part it was because commercial compsci R&D in the UK (and
Europe) was offshored to the USA (because of cheaper capital,
rather than cheaper labor, where Europe had the advantage), and
in part because the UK government policy for academic research
in compsci was to bet the farm on AI, perhaps inspired by the
japanese 5th gen project, with easily imagined/observed and
similar results :-).
Eugene Miya
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>>> "almost all programming can be viewed as an exercise in caching"
Eugene Miya wrote:
>> So Terje, you guys still producing heavy water?
>>
>Hmmm, I'll have to check...
>
>As of quite few years ago, when my father was the director of Hydro's
>Rjukan facility, we did indeed still make heavy water.
Yeah, you should know that in the USA there was a 1 hr. program
devoted to you know what and barrel recovery.
>However, afaik this production was tied to the manufacturing of rare
>gases, and that part of Hydro (mainly the original fertilizer
>facilities) has been fissioned out into a separate company, called Yara.
>http://www.yara.com does not tell me it they still make it. :-(
Stealth. 8^)
It's the Web vs. the real world. We have to get used to it.
--
Eugene Miya
Mark Smotherman <ma...@clemson.edu> wrote:
>eug...@cse.ucsc.edu (Eugene Miya) writes:
>>I like the duality of 7030 you put here, shows you are a man of quality
>>(and that life is full of hard choices).
>
>It wasn't clear in my original post - the list and entries should
Yeah. We have to stride the line anonymous review and opinion (anonmity
on Usenet is a joke) and full visibility. Dave Kotz used to "sign"
all his annotation in the parallel IO biblio he kept until he handed it
over. Before that time he stopped. I do a mix on mine (if you are
going to post: its on line; if via email completely anonyous or choice
of initials).
--
Eugene Miya
In article <yf37j17...@base.gp.example.com>,
Peter Grandi <pg...@0603.exp.sabi.co.UK> wrote:
>I nominate the Manchester MU4/Atlas and MU5 (and perhaps the MU6
>successor). They were important, well designed architectures
>that went on to considerable commercial success in one form or
>another (the MU4 as itself, the MU5 as the ICL 2900 series).
From reading, I suspect these are good choices.
Note more comment below.
>They both had some interesting first, e.g. MU4 for virtual
>memory, MU5 for a LAN distributed heterogenous OS.
Software is a trickier issue.
>The CPU architecture of both was in the usual and very effective
>Manchester style of specialized registers/accumulators (which in
>part inspired my idea of a 4-stack CPU).
>
>Disclaimer: I was briefly involved...
That's OK.
>There are several paper on both, with several bibliographic
>entries here:
>
> http://WWW.sabi.co.UK/Notes/csGreatObs.html
>
>and a collection of materials, including photos etc. around
>
> http://WWW.Computer50.org/kgill/
>
>As to books, some architecture books by Manchester people are
>pretty good, for example the MU5 related "The MU5 computer
>system" by Morris and Ibbett (MacMillan 1980) and the more
>general "The architecture of high-performance computers" by
>Ibbett and Topham (MacMillan 1989) which is a little known
>classic.
Oh yes I am aware of Ibbett and Topham.
%A Roland Ibbett
%A Nigel Topham
%T Architecture of High Performance Computers 2/E
%V 1
%I Springer-Verlag
%C New York
%D 1989
%K book, text, PARALLEL PROCESSING/SUPERCOMPUTERS,
%O ISBN #: 0387913521 $36.00
%A Roland Ibbett
%A Nigel Topham
%T Architecture of High Performance Computers 2/E
%V 2
%I Springer-Verlag
%C New York
%D 1989
%K book, text, PARALLEL PROCESSING/SUPERCOMPUTERS,
%O ISBN #: 038791353X $36.00
The all caps was from the Comp. Lit. bookshop database.
So it made it to Silicon Valley, but likely did not sell well.
>These were probably the last ''big iron''/research computer
>designs made in Europe. Manchester went on to do some work on
>dataflow and OO architectures, and Cambridge on capability
>systems and token ring, but they were not on the same scale.
Oh yes, I was on the periphery of the dataflow project.
Friends from LLL spent a lot of time there with SISAL and throttling.
There are people aware of dataflow.
I'd give some credit to various French projects and the SUPRENUM.
Ideally CHM should have a SUPRENUM and anything Manchester can save (its
just time before bureaucrats realize that physical space is a premium,
we are really the only people who care to preserve computers).
I have mixed opinions about token rings. Insufficient experience on my
part.
>In part it was because commercial compsci R&D in the UK (and
>Europe) was offshored to the USA (because of cheaper capital,
>rather than cheaper labor, where Europe had the advantage), and
>in part because the UK government policy for academic research
>in compsci was to bet the farm on AI, perhaps inspired by the
>japanese 5th gen project, with easily imagined/observed and
>similar results :-).
I have chanced to look through Wikipedia using supercomputers
as a test entry (it's more puffery now).
Recently I got to the 5th gen project.
The Grand Challenge entry was bad.
But it's amusing to me that in the 5th gen. there is a dangling pointer
to the Alvey project (despite a book being written on it).
It's going to be interesting to see what actually gets written about it
(will it be puffery or frank?).
--
Nick Maclaren
In article <44e4a1b2$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) writes:
|>
|> I have chanced to look through Wikipedia using supercomputers
|> as a test entry (it's more puffery now).
|> Recently I got to the 5th gen project.
|> The Grand Challenge entry was bad.
|> But it's amusing to me that in the 5th gen. there is a dangling pointer
|> to the Alvey project (despite a book being written on it).
|> It's going to be interesting to see what actually gets written about it
|> (will it be puffery or frank?).
If it were done well, it could become as classic of the nature of The
Mythical Man-Month.
I was told by a reliable source that there were three Alvey projects
that achieved a non-zero proportion of their proposed objectives; I know
two of them, but have never been able to identify the third.
There is an amusing story on this. There were several projects to solve
the problem of the static checking of array bounds / pointer scopes in
arbitrary programs. By chance, I saw a few proposals and noted that at
least two were equivalent to solving the Halting Problem. I met one of
the people in a bar later, and had a conversation like this:
Me: You do know, I assume, that your proposal is equivalent to solving
the Halting Problem?
Him: Yes, but I believe that we have found a way around it.
Me: Ah. Interesting. Please excuse me, as I have just spotted someone
I need a word with the other side of the bar.
Regards,
Nick Maclaren.
Tim McCaffrey
I would add the Whirlwind computer from MIT. I'm not sure of the ISA, but it
appears to be a more-or-less 16 bit version of a PDP-8 (Ken Olsen worked on
the Whirlwind, surprise!). The neat thing about it is that it was cleanly
engineered, was the second computer to use Magnetic Core memory (the first was
a computer to test core built from spares for the Whirlwind), and was used for
many years after it was built (at MITRE and Wolfram(?)). Many of the concepts
learned while building and maintaining Whirlwind were used to build SAGE. It
was tube based and was considered a "supercomputer" of its time (I think it
could run at about 50KIPS).
- Tim
NOT speaking for Unisys.
Nick Maclaren
In article <yf37j17...@base.gp.example.com>,
pg...@0603.exp.sabi.co.UK (Peter Grandi) writes:
|>
|> These [MU5] were probably the last ''big iron''/research computer
|> designs made in Europe. Manchester went on to do some work on
|> dataflow and OO architectures, and Cambridge on capability
|> systems and token ring, but they were not on the same scale.
Yes. The BBC Micro B was definitely something to admire and copy,
but mainly along the lines of how to put things together. It was in
fairly widespread use until very recently, which indicates how good
it was. And I still model my .emacs after BBC View - one of the best
designed editors ever :-)
There were other small-scale projects, too. The X.29 (X.25? I now
forget) PAD was designed and prototyped by my colleagues in the
Computing Service here, and may be the final commercial hardware
development by an academic-related department in a university
anywhere in the world. There were a fair number of earlier ones,
but I don't know of a later one.
Regards,
Nick Maclaren.
Eugene Miya
>entries here:
>
> http://WWW.sabi.co.UK/Notes/csGreatObs.html
I like these. I like the bit you quote Gio Wiederhold (I see him once or
twice a month in SF or Stanford).
You need to flesh it out a bit, you can replace one reference with:
%A J. R. Gurd
%A C. C. Kirkham
%A I. Watson
%T The Manchester Prototype Dataflow Computer
%J Communications of the CACM (CACM)
%V 28
%N 1
%D January 1985
%P 34-52
%K grecommended97/91(4): dmp, jlh, dp, jwvz,
%K define average parallelism - use speedup and efficiency,
%K parallel scheduling bib,
RPrice: dynamic allocation/fine-grain resolution,
%K CR Categories and Subject Descriptors:
C.1.3 [Processor Architectures]: Other Architecture Styles;
C.4 [ Performance of Systems];
D.3.2 [Programming Languages]: Language Classifications,
General Terms: Design, Languages, Performance,
Additional Key Words and Phrases: tagged-token dataflow,
single assignment programming, SISAL, parallel computation,
%X A special issue on Computer Architecture. Mentions SISAL, but not LLNL.
Using tagged-token dataflow, the Manchester processor is running
reasonably large user programs at maximum rates of between 1 and 2 MIPS.
Reproduced in "Selected Reprints on Dataflow and Reduction Architectures"
ed. S. S. Thakkar, IEEE, '87, pp. 111-129.
%X (JH & DP) This paper discusses the machine, its software, and
evaluates performance.
%X Price: Provides an excellent description and overview of
tagged token data flow architecture. A first-in-first-out token queue
has the effect of smoothing the rates of toek generation and consumption.
Packets are executed by a Processing Unit in which packets are routed
via a distribution bus to the first available function units.
%X (GFP) Description of one of the few live, working dataflow machine
ever every constructed; done by the University of Manchester.
This work was quite influential and often cited in dataflow literature.
The refer %B book field is for paper/chapters titled inside books (the %B).
Titled books should just use %T.
There's a bunch of others. But I have to run to meetings.
>and a collection of materials, including photos etc. around
>
> http://WWW.Computer50.org/kgill/
--
Eugene Miya
>|> I have chanced to look through Wikipedia using supercomputers
>|> But it's amusing to me that in the 5th gen. there is a dangling pointer
>|> to the Alvey project (despite a book being written on it).
>|> It's going to be interesting to see what actually gets written about it
>|> (will it be puffery or frank?).
In article <ec28r8$6pe$1...@gemini.csx.cam.ac.uk>,
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>If it were done well, it could become as classic of the nature of The
>Mythical Man-Month.
It's Wikipedia Nick. It's Wikipedia.
A Brit associated with the project (or not) can start with a straw man
then it gets opened up to the world.
>I was told by a reliable source that there were three Alvey projects
>that achieved a non-zero proportion of their proposed objectives; I know
>two of them, but have never been able to identify the third.
Well I could attempt to relocate the Alvey book (time consuming)
and do a book report as a straw man, but why do the work for the Brits.
Why not you Nick?
>There is an amusing story on this. There were several projects to solve
>the problem of the static checking of array bounds / pointer scopes in
>arbitrary programs. By chance, I saw a few proposals and noted that at
>least two were equivalent to solving the Halting Problem. I met one of
>the people in a bar later, and had a conversation like this:
>
>Me: You do know, I assume, that your proposal is equivalent to solving
>the Halting Problem?
>
>Him: Yes, but I believe that we have found a way around it.
>
>Me: Ah. Interesting. Please excuse me, as I have just spotted someone
>I need a word with the other side of the bar.
Operating systems and network protocols are merely 2 examples of the
irrelevance of the Halting problem. I mean interesting theory, but a
morass to let others trisect arbitrary angles.
--
Eugene Miya
>
>Mythical Man-Month.
>
>I was told by a reliable source that there were three Alvey projects
>that achieved a non-zero proportion of their proposed objectives; I know
Actually, I now see that in the last 2 days someone has put up an
initial page.
--
Eugene Miya
=?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbr...@not-mediasec.de> wrote:
> From my point of view, add the early transputers, in particular the
>T800. All you need on one chip: processor, memory, network interface,
>OS 8-).
I agree with you on the Transputer, however, above all I would prefer
(Mark's list) to distinguish CPUs from complete systems.
I am not certain how to handy software, but a 6502 (which I only know
little about is one thing, a number of people designed 6502 basd systems),
and Apple 2 (with a 6502) and Woz's floppy disk controller (and system)
rates higher than just the mere 6502 (and that's low end).
>OTOH, the T9000 is split: the VCP (virtual channel processor) I admire,
>the rest is more of a counter-example, in no small part due to bad
>implementation.
Mark, you have your work cut out for you.
--
Jim Haynes
from B-6500 on.
--
jhhaynes at earthlink dot net
Terje Mathisen
> In article <93fdr3-...@osl016lin.hda.hydro.com>,
> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>>>> "almost all programming can be viewed as an exercise in caching"
>
> Eugene Miya wrote:
>>> So Terje, you guys still producing heavy water?
>>>
>> Hmmm, I'll have to check...
>>
>> As of quite few years ago, when my father was the director of Hydro's
>> Rjukan facility, we did indeed still make heavy water.
>
> Yeah, you should know that in the USA there was a 1 hr. program
> devoted to you know what and barrel recovery.
Recent articles in the Norwegian press indicates that there are firm
plans to make yet another film about the event.
Reading the full story is simply amazing: You'd be hard pressed to put
so many incredible events into a single script.
Here's just a few of the things I remember:
a) Nobody (Norwegian or German) was killed or (badly) injured by/during
the sabotage action. (They had to knock down a lone Norwegian guard they
found inside the plant, this was to give him plausible deniability, so
the Germans wouldn't shoot him.)
b) They gained access by climbing down into and back out of a river
canyon so steep that the German Alpine/Mountain troops stationed there
had simply classed it as unpassable. They did it at night, in winter.
c) Nobody had even considered the possibility of escaping after the
action, so they didn't have any real plans for getting away. In the end
they skied across all the mountains west of Rjukan, ending up in Sweden.
d) The Germans employed more than 10 K troops to find them afterwards,
including all of their crack alpine/mountain troops, they got very,
_very_ close multiple times but never quite managed.
e) With no food supply while hiding away in the middle of the mountains
they got real close to dying of hunger, but at the end the strongest guy
remaining finally found a herd of reindeer and managed to shoot one.
They ate _everything_ from that deer, including the contents of the
intestines since one of them knew that this could be a source of Vitamin
C, needed to avoid scurvy.
One guy who stayed behind in Norway (Claus Helberg, originally from
Rjukan) got captured once or twice, but managed to escape, the last time
by jumping from a (moving) bus transporting him from hospital (he had
broken an arm) to German interrogation headquarters.
f) When the Germans finally gave up and decided to transport all the
remaining stocks of more or less concentrated D2O, two guys from the
same group managed to sneak into the keel space of the (railroad) ferry
that was going to handle the first part of the transport. There they
placed a bomb with a timer, set to sink the ferry at the deepest point
of the lake (300+ m). Trusting in German punctuality, they could
calculate the proper time very closely, and it worked, literally like
clockwork. (This was a classic IED (Improvised Explosive Device), using
a mechanical alarm clock as the timer! :-)
Terje
--
- <Terje.M...@hda.hydro.com>
Terje Mathisen
> Operating systems and network protocols are merely 2 examples of the
> irrelevance of the Halting problem. I mean interesting theory, but a
> morass to let others trisect arbitrary angles.
Ouch.
I once had a math teacher (in secondary school) who actually believed he
had found a way to do this, he buttonholed me once, made me spend an
hour when he went over his geometrical proof of how it worked.
It didn't take very long to figure out that what he had was a neat way
to get arbitrarily close (something like a NR iteration doubling the
number of significant digits each iteration), but that was it. :-(
Nick Maclaren
In article <qk3gr3-...@osl016lin.hda.hydro.com>,
Terje Mathisen <terje.m...@hda.hydro.com> writes:
|> Eugene Miya wrote:
|> > Operating systems and network protocols are merely 2 examples of the
|> > irrelevance of the Halting problem. I mean interesting theory, but a
|> > morass to let others trisect arbitrary angles.
|>
|> Ouch.
|>
|> I once had a math teacher (in secondary school) who actually believed he
|> had found a way to do this, he buttonholed me once, made me spend an
|> hour when he went over his geometrical proof of how it worked.
|>
|> It didn't take very long to figure out that what he had was a neat way
|> to get arbitrarily close (something like a NR iteration doubling the
|> number of significant digits each iteration), but that was it. :-(
Yes. Those of us with experience in global optimisation and related
areas know how common it is to get "good enough" solutions to impossible
problems. But they ALL have the characteristic that there are nasty
cases where they plain don't work, which can arise either if you are
very unlucky or are being attacked.
When producing chemical or nuclear plant control systems, I don't
agree that "well, it usually works" is good enough. I know that I am
heretical in this respect.
Even with ordinary systems administration, I have noticed how much the
main failure mode has shifted from "plain" bugs to the occurrence of
"unlikely" cases which were deliberately not catered for. In many
environments, the MAIN cause of failure is now the latter.
Regards,
Nick Maclaren.
Nick Maclaren
In article <44e4e2ae$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) writes:
|>
|> >|> But it's amusing to me that in the 5th gen. there is a dangling pointer
|> >|> to the Alvey project (despite a book being written on it).
|> ^^^^^^^^^^^^^
|> >|> It's going to be interesting to see what actually gets written about it
|> >|> (will it be puffery or frank?).
|>
|> >Mythical Man-Month.
|>
|> It's Wikipedia Nick. It's Wikipedia.
So? Move with the times! Who will take bets on when the first Wikipedia
entry is written that becomes a classic? Already done? 2010? 2020?
Never?
|> Well I could attempt to relocate the Alvey book (time consuming)
|> and do a book report as a straw man, but why do the work for the Brits.
|> Why not you Nick?
Because the book wasn't enough of a classic. Someone would have to do
the basic research and write it up well. I was nowhere near close enough
to enough of the action, even if my writing were good enough.
Regards,
Nick Maclaren.
Edward Feustel
"Jim Haynes" <hay...@alumni.uark.edu> wrote in message
news:v29Fg.7273$Qf....@newsread2.news.pas.earthlink.net...
There are some machines with features not in the above list.
1. Connectivity: the early Thinking Machines (not the CM5), The Transputer
and connectivity
chips,
2. Protection: Iliffe's BLM, Intel's ill fated projects: 432, and BiiN (960
XM), the Cambridge CAP Machine,
3. Vectors: CDC Star 100, 205
4. Message Passing: ELXSI
5. Computing in memory: ICL DAP, Goodyear ASP
While it is true that these machines were not commercial successes, it is
instructive to study them for the ideas that they embodied and to note that
some of the ideas may be worthwhile pursuing when technology or "societal
forces" permit/require them.
Ed Feustel
Nick Maclaren
In article <qtCdnWOQR7VdBnjZ...@giganews.com>,
"Edward Feustel" <efeu...@hughes.net> writes:
|>
|> How about categorizing the architectures for their "breakthrough features"?
|> There are some machines with features not in the above list.
And there are an even larger number with at least one such feature,
such as the Hitachi SR2201.
But the original list was very USA-centric. Peter Grandi has already
pointed out the incredibly influential Atlas - though many of its
features need rediscovering. And, obviously, the Manchester Baby
and Edsac I absolutely HAD to have breakthrough features :-)
Regards,
Nick Maclaren.
JJ
I'd be interested to know more about the Rekursiv machine from U
Glasgow and what others think of its object support in hardware. I
think they built up to 30 of them so definitely a research
architecture.
John Jakson
transputer guy
Terje Mathisen
> Even with ordinary systems administration, I have noticed how much the
> main failure mode has shifted from "plain" bugs to the occurrence of
> "unlikely" cases which were deliberately not catered for. In many
> environments, the MAIN cause of failure is now the latter.
My normal way to put this is that:
'All the simple bugs have been found by now, it is those that depend on
several seemingly unrelated events that remain.'
Nick Maclaren
In article <makgr3-...@osl016lin.hda.hydro.com>,
Terje Mathisen <terje.m...@hda.hydro.com> writes:
|> Nick Maclaren wrote:
|> > Even with ordinary systems administration, I have noticed how much the
|> > main failure mode has shifted from "plain" bugs to the occurrence of
|> > "unlikely" cases which were deliberately not catered for. In many
|> > environments, the MAIN cause of failure is now the latter.
|>
|> My normal way to put this is that:
|>
|> 'All the simple bugs have been found by now, it is those that depend on
|> several seemingly unrelated events that remain.'
I wish that even that were true :-(
The number of simple bugs does not appear to be dropping, but they are
(a) relatively quick to locate, (b) often easy to bypass and (c) linear
in the 'size' of the system.
It is the complex ones that are increasing, partly due to the fact that
their number is non-linear in the 'size' of the system, and partly
because the only way to keep them under control is to use a clean,
validatable design and precisely specified primitives. And those are
just SO out of fashion.
Regards,
Nick Maclaren.
(see below)
1155899542.1...@m79g2000cwm.googlegroups.com, "JJ"
<johnj...@gmail.com> wrote:
> I'd be interested to know more about the Rekursiv machine from U
> Glasgow and what others think of its object support in hardware.
While the Rekursiv's principal architect, David Harland,
had been a CS lecturer at Glasgow University,
he left to join Linn (a hi-fi audio company based near Glasgow)
which is where the Rekursiv was designed and built.
> I think they built up to 30 of them so definitely a research
> architecture.
Although partly based on work he had done at GUCS,
the Rekursiv was an (unsuccessful) attempt by Linn at a product,
not a Glasgow University research project.
--
Bill Findlay <surname><forename> chez blueyonder.co.uk
(unpaid consultant on the design of the Rekursiv for one afternoon)
Del Cecchi
> Eugene Miya wrote:
>
>> Operating systems and network protocols are merely 2 examples of the
>> irrelevance of the Halting problem. I mean interesting theory, but a
>> morass to let others trisect arbitrary angles.
>
>
> Ouch.
>
> I once had a math teacher (in secondary school) who actually believed he
> had found a way to do this, he buttonholed me once, made me spend an
> hour when he went over his geometrical proof of how it worked.
>
> It didn't take very long to figure out that what he had was a neat way
> to get arbitrarily close (something like a NR iteration doubling the
> number of significant digits each iteration), but that was it. :-(
>
> Terje
>
There is a clever construction that comes quite close for acute angles.
Totally freaked out my High School (10th grade) geometery teacher, as
she had no idea how to prove you can't trisect an angle but merely
parroted the fact.
I could probably reproduce the method if I had to.
--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions,
strategies or opinions.”
Eugene Miya
>>
>> had found a way to do this, he buttonholed me once, made me spend an
>> hour when he went over his geometrical proof of how it worked.
>>
>> It didn't take very long to figure out that what he had was a neat way
>> to get arbitrarily close (something like a NR iteration doubling the
>> number of significant digits each iteration), but that was it. :-(
In article <4km3mgF...@individual.net>,
Del Cecchi <cecchi...@us.ibm.com> wrote:
>There is a clever construction that comes quite close for acute angles.
> Totally freaked out my High School (10th grade) geometery teacher, as
>she had no idea how to prove you can't trisect an angle but merely
>parroted the fact.
It's a five minute algebra proof which was commonly used to
show algebra's superiority over geometry which was commonly done at the
start of abstract algebra classes on the way to Galois theory and coding
theory. It basically boils down to the indivisibility (you have a
reminder or modulus) of 3/2 from an era of direct solution.
Of course you can also approximate with a protractor or with right angles.
But then they wanted to wow us with Hamming codes.
Truly a wow.
--
Eugene Miya
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>In article <44e4e2ae$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) writes:
>
>So? Move with the times!
>|> Why not you Nick?
>
>Because the book wasn't enough of a classic. Someone would have to do
No Nick, you miss the basic point: because you are lazy.
It doesn't matter that it would otherwise be anonymous, etc.
--
Eugene Miya
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>>>>> "almost all programming can be viewed as an exercise in caching"
>>>
>> devoted to you know what and barrel recovery.
Well, I think the thing to do may is buy some.
>Recent articles in the Norwegian press indicates that there are firm
>plans to make yet another film about the event.
>
>Reading the full story is simply amazing: You'd be hard pressed to put
>so many incredible events into a single script.
The current story is merely about recovering the barrel.
>Here's just a few of the things I remember:
>
>a) Nobody (Norwegian or German) was killed or (badly) injured by/during
>the sabotage action.
At first I was thinking you meant the ferry.
>inside the plant,
The other stuff is summarized in one N.-documentary (if not more) and
and one old popular movie.
But actually what's interesting is the different grades (%s) of D2O.
--
Eugene Miya
Edward Feustel <efeu...@hughes.net> wrote:
>"Jim Haynes" <hay...@alumni.uark.edu> wrote in message
>news:v29Fg.7273$Qf....@newsread2.news.pas.earthlink.net...
>>>Mark Smotherman wrote:
>>>> #1 - admired designs
>> I'm amazed by the omission of Burroughs B-5000 and its successors
>> from B-6500 on.
What's to be amazed?
Hey: it's Mark's list, and he's got his own editorial interests.
He's got a lot of IBM hardware, and IBM folk have a lot of baggage.
One can make up one's own separate list. I lived near a Burroughs
factory for 4 years and knew a number of their ANSI people but never
used their machines, but I heard mixed value to stack machines.
>How about categorizing the architectures for their "breakthrough features"?
This is a good idea.
>There are some machines with features not in the above list.
>
>1. Connectivity: the early Thinking Machines (not the CM5), The Transputer
>and connectivity chips,
OK, to play devils advocate: why the CM and not the MPP? Was it a media
decision? Did you program on it? etc.
>2. Protection: Iliffe's BLM, Intel's ill fated projects: 432, and BiiN (960
>XM), the Cambridge CAP Machine,
>3. Vectors: CDC Star 100, 205
>4. Message Passing: ELXSI
Get Rich Maine in comp.lang.fortran, he had one. He's also in a.f.c.
on occasion.
>5. Computing in memory: ICL DAP, Goodyear ASP
I saved a DAP as a representative non-US machine for CHM.
I lucked out.
>While it is true that these machines were not commercial successes, it is
>instructive to study them for the ideas that they embodied and to note that
>some of the ideas may be worthwhile pursuing when technology or "societal
>forces" permit/require them.
Well I think any decent system in history should have a frank commercial
analysis. I think the lessons there should be more for engineers to
track the performance of firms they may start.
There's a separate software thread happening in a.f.c
--
Eugene Miya
In article <qtCdnWOQR7VdBnjZ...@giganews.com>,
"Edward Feustel" <efeu...@hughes.net> writes:
>|> How about categorizing the architectures for their "breakthrough features"?
>|> There are some machines with features not in the above list.
In article <ec471q$5fq$1...@gemini.csx.cam.ac.uk>,
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>And there are an even larger number with at least one such feature,
>such as the Hitachi SR2201.
>
>But the original list was very USA-centric.
So make your own separate list and be prepared to reference and justify
your points as Mark is capable.
--
Nick Maclaren
In article <44e5f282$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) writes:
|> In article <4km3mgF...@individual.net>,
|> Del Cecchi <cecchi...@us.ibm.com> wrote:
|> >There is a clever construction that comes quite close for acute angles.
|> > Totally freaked out my High School (10th grade) geometery teacher, as
|> >she had no idea how to prove you can't trisect an angle but merely
|> >parroted the fact.
|>
|> It's a five minute algebra proof which was commonly used to
|> show algebra's superiority over geometry which was commonly done at the
|> start of abstract algebra classes on the way to Galois theory and coding
|> theory. It basically boils down to the indivisibility (you have a
|> reminder or modulus) of 3/2 from an era of direct solution.
Yes, that's the primary school solution. For the secondary school one,
spot at least one unproven assumption in that proof. For the university
level one, do the proof properly.
Regards,
Nick Maclaren.
Peter Grandi
>>> Miya) said:
[ ... ]
pg> http://WWW.sabi.co.UK/Notes/csGreatObs.html
eugene> I like these. I like the bit you quote Gio Wiederhold (I
eugene> see him once or twice a month in SF or Stanford).
Tell him that he has got a big fan of his stuff! That book is
amazingly good.
eugene> You need to flesh it out a bit, [ ... ]
I jot down things and then every now and then occasionally
I have a go at fleshing them out. But it is so pointless and
sad. It makes me a bit depressed to go through that. I think
that the current state of compsci is very well captured here:
http://WWW.iBiblio.org/Dave/Dr-Fun/df200002/df20000210.jpg
eugene> The refer %B book field is for paper/chapters titled
eugene> inside books (the %B). Titled books should just use
eugene> %T. [ ... ]
Yes, and the difference between a book and an article is the
latter has a %J. But then I developed my own 'refer' macros for
nicer biblio layout (not used them in several years) and then
discovered that the default convention is not very good and
chose to make my own. In retrospect compatibility looks more
important. Anyhow, not many people are still using 'refer', not
even in its TeX variant, and that bibliography is so pointless
anyhow... But I'll switch back to the default convention next
time I can bring myself to update that list... :-).
Terje Mathisen
> In article <ja3gr3-...@osl016lin.hda.hydro.com>,
> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>> a) Nobody (Norwegian or German) was killed or (badly) injured by/during
>> the sabotage action.
>
> At first I was thinking you meant the ferry.
Oh, no. That part is still being discussed by the survivors and their
families.
> But actually what's interesting is the different grades (%s) of D2O.
That was a result of the process used: The chemical difference between
H20 and D20 isn't big enough to allow a large increase in concentration
from a single processing stage.
Afair they needed hundreds of iterations to end up with the pure stuff.
Terje
--
- <Terje.M...@hda.hydro.com>
Terje Mathisen
> Terje Mathisen wrote:
>> I once had a math teacher (in secondary school) who actually believed
>> he had found a way to do this, he buttonholed me once, made me spend
>> an hour when he went over his geometrical proof of how it worked.
>
Trivial to extend to all angles then: Just start by dividing it in four,
then trisect the second quartile. Adding the first back in and you've
gotten your answer, right?
> Totally freaked out my High School (10th grade) geometery teacher, as
> she had no idea how to prove you can't trisect an angle but merely
> parroted the fact.
Sort of the opposite to my situation then. :-)
Peter Grandi
>>> <terje.m...@hda.hydro.com> said:
terje.mathisen> Eugene Miya wrote:
>> Operating systems and network protocols are merely 2 examples of
>> the irrelevance of the Halting problem. I mean interesting
>> theory, but a morass to let others trisect arbitrary angles.
terje.mathisen> [ ... trisection ... ] It didn't take very long
terje.mathisen> to figure out that what he had was a neat way to
terje.mathisen> get arbitrarily close (something like a NR
terje.mathisen> iteration doubling the number of significant
terje.mathisen> digits each iteration), but that was it. :-(
Halting problem? Arbitrarily close? I feel the urge to mention my
discovery of how to solve the halting problem using a Zeno-style
computer!
All you have to do is to build a Zeno-style computer, which
executes the first instruction is half a second, the second in a
quarter of a second, and so on doubling the speed of execution on
each instruction. Let's call this computer Achilles Mark I :-).
Then if the Zeno computer stops executing before exactly 1
second has elapsed, the program' execution terminated; if it
stops exactly after one second, the program's execution did
not terminate. :-)
It may be a thought experiment, but it is has some amusing
sides... :-)
Eugene Miya
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>> But actually what's interesting is the different grades (%s) of D2O.
>
>That was a result of the process used: The chemical difference between
>H20 and D20 isn't big enough to allow a large increase in concentration
>from a single processing stage.
Oh yes, they went into that.
>Afair they needed hundreds of iterations to end up with the pure stuff.
Early algorithms.
Societies are getting into the Ks, and 10Ks of things now.
But they insist on direct solution.
--
Eugene Miya
Peter Grandi <pg...@0603.exp.sabi.co.UK> wrote:
>pg> http://WWW.sabi.co.UK/Notes/csGreatObs.html
>
>eugene> I like these. I like the bit you quote Gio Wiederhold (I
>eugene> see him once or twice a month in SF or Stanford).
>
>Tell him that he has got a big fan of his stuff! That book is
>amazingly good.
I'm not a DB type. I mostly just use a linear sequence of bytes....
>eugene> You need to flesh it out a bit, [ ... ]
>
>I jot down things and then every now and then occasionally
>I have a go at fleshing them out. But it is so pointless and
>sad. It makes me a bit depressed to go through that. I think
oh?
>that the current state of compsci is very well captured here:
>
> http://WWW.iBiblio.org/Dave/Dr-Fun/df200002/df20000210.jpg
8^) I suspect (since this is 2K) he has seen this.
>eugene> refer
>
>Yes, and the difference between a book and an article is the
>latter has a %J. But then I developed my own 'refer' macros for
I figured that.
>nicer biblio layout (not used them in several years) and then
>discovered that the default convention is not very good and
>chose to make my own. In retrospect compatibility looks more
>important.
Quite bright.
>Anyhow, not many people are still using 'refer', not
>even in its TeX variant, and that bibliography is so pointless
>anyhow... But I'll switch back to the default convention next
>time I can bring myself to update that list... :-).
I am still thinking about what you assembled.
TeX just came up in a.f.c.
--
John Dallman
terje.m...@hda.hydro.com (Terje Mathisen) wrote:
> Reading the full story is simply amazing: You'd be hard pressed to
> put so many incredible events into a single script.
I'm sure you know these titles but others may be interested:
Per F Dahl: _Heavy Water and the wartime race for nuclear energy_,
by an ex-Lawrence Livermore guy who had the use of the Norsk Hydro
archives, Institute of Physics (UK) press, 1999.
Jeremy Bernstein: _Hitler's Uranium Club_, the best book on what the
Germans did and didn't know about nuclear weapons during WWII, America
Institute of Physics, 1996.
> c) Nobody had even considered the possibility of escaping after the
> action, so they didn't have any real plans for getting away...
It was, unquestionably, one of the bravest actions of WWII.
---
John Dallman j...@cix.co.uk
"Any sufficiently advanced technology is indistinguishable from a
well-rigged demo"
Eugene Miya
John Dallman <j...@cix.co.uk> wrote:
>Jeremy Bernstein: _Hitler's Uranium Club_, the best book on what the
>Institute of Physics, 1996.
Hmmm.
I think Sam Goudsmit's own book Alsos is a hair better.
I just finished the more recent Spying on the Bomb (more current to work
events, and you can see ineffective camo on the Chinese gas diffusion plant,
and why everyone now builds underground).
While I did my 1st trip to London, I saw the play Copenhagen.
I don't recommend it (too cute and arty compromises certain facts).
>"Any sufficiently advanced technology is indistinguishable from a
>well-rigged demo"
Very good.
--
John Dallman
> I think Sam Goudsmit's own book Alsos is a hair better.
> I just finished the more recent Spying on the Bomb
<a href="amazon.co.uk" action="purchase">
> While I did my 1st trip to London, I saw the play Copenhagen.
> I don't recommend it (too cute and arty compromises certain facts).
Dramatisations, for stage, screen or radio have a common flaw. They have
to leave out too much, and they have to, well, dramatise.
> >"Any sufficiently advanced technology is indistinguishable from a
> >well-rigged demo"
> Very good.
Thank you! Inspired by Clarke, and computer manufacturers.
---
John Dallman j...@cix.co.uk
Nick Maclaren
In article <memo.2006081...@jgd.compulink.co.uk>,
j...@cix.co.uk (John Dallman) writes:
|>
|> > While I did my 1st trip to London, I saw the play Copenhagen.
|> > I don't recommend it (too cute and arty compromises certain facts).
|>
|> Dramatisations, for stage, screen or radio have a common flaw. They have
|> to leave out too much, and they have to, well, dramatise.
The problem about that one wasn't that they left out too much, but that
they had to invent too much because there weren't enough known facts!
God alone knows what was said at that meeting ....
Regards,
Nick Maclaren.
Dennis M. O'Connor
> eug...@cse.ucsc.edu (Eugene Miya) wrote:
>> >"Any sufficiently advanced technology is indistinguishable from a
>> >well-rigged demo"
>>
>> Very good.
>
> Thank you! Inspired by Clarke, and computer manufacturers.
It's old. First USENET reference on google is in 1988,
and attributed to Andy Finkel. At that time it was already
part of a "cookie" program, so it's older than that.
I first heard it back around 1982, at GE's Corporate R&D Center.
Saw it used, too: to sell a research product to develop an advanced
automated inspection system, they made a video of "the system in
action" that had people standing off-camera pushing and pulling
the pieces around, since they didn't have the automation components
developed yet. Doing it with computer graphics wasn't practical then.
--
Dennis M. O'Connor dm...@primenet.com
Eugene Miya
>|> > I don't recommend it (too cute and arty compromises certain facts).
In article <memo.2006081...@jgd.compulink.co.uk>,
j...@cix.co.uk (John Dallman) writes:
>|> Dramatisations, for stage, screen or radio have a common flaw. They have
>|> to leave out too much, and they have to, well, dramatise.
True. Terje and others from Norway cringes at the Kirk Douglas film
but it has continuity.
In article <ec7161$rm0$1...@gemini.csx.cam.ac.uk>,
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>The problem about that one wasn't that they left out too much, but that
>they had to invent too much because there weren't enough known facts!
>God alone knows what was said at that meeting ....
I have to agree with Nick on this one. The stuff mentioned in the play
about Pu had to have been fabricated, and they made Bohr's wife a woman
of the present day.
--
Terje Mathisen
> In article <ja3gr3-...@osl016lin.hda.hydro.com>,
> terje.m...@hda.hydro.com (Terje Mathisen) wrote:
>
>> Reading the full story is simply amazing: You'd be hard pressed to
>> put so many incredible events into a single script.
>
> I'm sure you know these titles but others may be interested:
>
> Per F Dahl: _Heavy Water and the wartime race for nuclear energy_,
> by an ex-Lawrence Livermore guy who had the use of the Norsk Hydro
> archives, Institute of Physics (UK) press, 1999.
>
> Jeremy Bernstein: _Hitler's Uranium Club_, the best book on what the
> Germans did and didn't know about nuclear weapons during WWII, America
> Institute of Physics, 1996.
>
>> c) Nobody had even considered the possibility of escaping after the
>> action, so they didn't have any real plans for getting away...
>
> It was, unquestionably, one of the bravest actions of WWII.
Seems the various military commanders thought so as well, they ended up
the single most heavily decorated group from the entire war.
While googling around, I found that the CIA has an English translation
of the report Claus Helberg wrote for the Norwegian Mountain Touring
Association in 1947:
https://www.cia.gov/csi/kent_csi/docs/v36i3a11p_0001.htm
One of the interesting points is that even two years after the end of
the war, much was still considered secret, in particular the names of
most of the team! In his report Claus writes about 'our team leader',
'another team leader', a 'team member' etc.
One of those team members, Knut Haugland, has a daughter who now works
for Hydro in the same section as me. :-)
Some years later he joined Thor Heyerdahl on the Kon Tiki expedition.
When one of the other men fell overboard, Knut was the guy who
immediately grabbed their longest rope, threw one end to one of the
other expedition members, and grabbed the other in his teeth, swimming
as fast as possible backwards to reach the MOB, who was trying (and
failing) to keep up with the raft which kept on sailing along.
Knut did reach him, saving his life.
Anyway, if there are any cross country skiers here, I'd like to invite
you to Telemark, Rjukan and the Hardangervidda!
Eugene Miya
So now Mark, you started a thread which generated some content
some of which helps your web site after consuming a few neurons, etc.
what are you going to do different which distinguished this thread from
all prior threads of this type which ties back to David's Mores thread?
--
Peter "Firefly" Lund
>> But the original list was very USA-centric.
>
> So make your own separate list and be prepared to reference and justify
> your points as Mark is capable.
No need to be condescending and call Nick lazy, especially when you
yourself is too lazy to write parseable English.
Anyway, a non-US list:
o Z[1234] - fascinating how much Zuse got right, how early he did it and
how little he had to learn from others.
o Pilot ACE - fast. Very fast. Turing's machine. Reputedly hard to
program for if you weren't a Turing-scale genius.
o Atlas - interrupts, virtual memory, supervisor. Remarkable how much
they got right so early with so little hardware.
o LEO - very early commercial computer - had to consider fast
people-oriented I/O and had to be stable and reliable.
Was used for daily inventory runs for hundreds of teashops.
Was also used for very early leased machine shops.
Multi-tasked.
o GIER - could be used more or less as a desktop PC and was sold as such
to technical universities, natural science institutes.
The machine Naur did his Algol 60 compiler for.
If anybody knows more about the Pilot ACE design, then I'm all ears :)
-Peter
Andy Glew
Anyone willing to discuss / present this?
I'vde never really studied ELXSI. Would like to learn.
Stephen Fuld
"Andy Glew" <first...@employer.domain> wrote in message
news:peypwt8ye...@PXPL8591.amr.corp.intel.com...
>> 4. Message Passing: ELXSI
>
> Anyone willing to discuss / present this?
>
> I'vde never really studied ELXSI. Would like to learn.
I looked at this system for a brief time in the mid 1980s. I am sure there
are people who know much more than I do, but I will start.
Elixi (based in silicon valley) produced a bus based symmetric
multi-processing system (sort of like the early Sequent or Encore machines).
Each processor was a single card containing iirc a single custom ECL
processor. Other cards contained memory and I/O interfaces. It was a wide
refrigerator sized machine that used a lot of power. I believe the OS was a
Unix derivative. The instruction set was pretty conventional except for the
additional message passing instructions. These allowed an area of memory
(a message) to be sent from one process to another with a single
instruction. One thing I liked was that the same mechanism was used for OS
calls. To get an OS service, you sent a message to the kernel.
They had working systems and probably even sold a few, but just couldn't
make it business wise.
That is about all I can remember. I had a complete set of user
documentation, but that is long gone.
Hope this helps and that others can help more.
--
- Stephen Fuld
e-mail address disguised to prevent spam
Eugene Miya
On Fri, 18 Aug 2006, Eugene Miya wrote:
>> So make your own separate list and be prepared to reference and justify
>> your points as Mark is capable.
>Anyway, a non-US list:
> o Z[1234] - fascinating how much Zuse got right, how early he did it and
> how little he had to learn from others.
> o Pilot ACE - fast. Very fast. Turing's machine. Reputedly hard to
> program for if you weren't a Turing-scale genius.
> o Atlas - interrupts, virtual memory, supervisor. Remarkable how much
> they got right so early with so little hardware.
> o LEO - very early commercial computer - had to consider fast
> people-oriented I/O and had to be stable and reliable.
> Was used for daily inventory runs for hundreds of teashops.
> Was also used for very early leased machine shops.
> Multi-tasked.
> o GIER - could be used more or less as a desktop PC and was sold as such
> to technical universities, natural science institutes.
> The machine Naur did his Algol 60 compiler for.
These are important inputs. A decent list.
>If anybody knows more about the Pilot ACE design, then I'm all ears :)
The List so far isn't merely US Centric. While you and I have posted 2
German examples most English speakers are not aware, no has even vaguely
considered computer developments from France (e.g. Lau), Spain, much of
the rest of Latin America, India (Elxsi was noted and I have run on one)
but there are other machines there, Japan, or China.
>No need to be condescending and call Nick lazy,
It's Nick's "tit" for his "tat;" for his own condescention.
He has far less info than he lets on. I guess you were not here
when he was pressed for more detail in his "positive" academic references,
and he cited that other aspects were mere "engineering" details.
>especially when you
>yourself is too lazy to write parseable English.
While true, it has its advantages extracting information from some
people (who project a lot to fill in blanks in interesting ways, and
it also tells me that strict langauge adherents are not as likely to
make advancements.
--
Eugene Miya
Mark and I have been exchanging some email on what to do: how to
abstract was has been suggested.
First and foremost, as I look at the suggestions, as I think about some
of the friends I have been lucky to know over the past 2 decades since
moving to Silicon Valley, considering ISCA and past lists (everyone
noting features like (not to pick on) stack machines, the B5000 [don't
get me wrong, I had friends at a couple of Burroughs plants]),
the first thing which screams out at me is:
RISC/Unix (as opposed to Multics)
this is why the 801, the MIPS, SOAR, etc. why the 6600 and Cray get
credited, H&P, etc. We were hit with featuritis. We are limited by our
own experience. We have to think how much and what we are going to get
out of any list. von Neumann machines are comparatively easy to
architect.
Second, I think it's easy to cite one-lines: a name for an architecture.
But the problem is gaining acceptance from those who have not had the
experience. Using the B5K example: I'm not so certain in this day of
RAM and PRAM models that stacks are relevant any more: HP calculators,
web browsers, directory stacks in shells, graphics systems, etc.,
not with standing. Did we really use these because we wanted to (say)
save memory? Cray didn't. Was he stupid? That reminds me that I have
to email Gombosi. So I think Mark, you need to flesh out and select
with the group what admiration is to separate puppy love from real info.
We are going to make mistakes again and again, but reinventing the wheel
did get steel belted radials (makes me wonder what our equivalent will be?).
--
Eugene Miya
Stephen Fuld <s.f...@PleaseRemove.att.net> wrote:
>"Andy Glew" <first...@employer.domain> wrote in message
>news:peypwt8ye...@PXPL8591.amr.corp.intel.com...
>>> 4. Message Passing: ELXSI
>> Anyone willing to discuss / present this?
Talk to Rich Maine in alt.folklore.computers or easier comp.lang.fortran.
>> I've never really studied ELXSI. Would like to learn.
>
>I looked at this system for a brief time in the mid 1980s. I am sure there
>are people who know much more than I do, but I will start.
Rich had one. 4 processors. I took a photo buried some where.
>Elixi (based in silicon valley) produced a bus based symmetric
Actually it was an Indian company.
>multi-processing system (sort of like the early Sequent or Encore machines).
>Each processor was a single card containing iirc a single custom ECL
>processor. Other cards contained memory and I/O interfaces. It was a wide
>refrigerator sized machine that used a lot of power. I believe the OS was a
>Unix derivative. The instruction set was pretty conventional except for the
EMBOS was an early sort of joke when the well-meaning Elxsi guys
"It's Unix-like." "We renamed name obscure Unix commands like
grep to find."
"What did you rename find to?"
They did come out with a native ENIX.
>additional message passing instructions. These allowed an area of memory
>(a message) to be sent from one process to another with a single
>instruction. One thing I liked was that the same mechanism was used for OS
>calls. To get an OS service, you sent a message to the kernel.
>
>They had working systems and probably even sold a few, but just couldn't
>make it business wise.
See above.
>That is about all I can remember. I had a complete set of user
>documentation, but that is long gone.
>
>Hope this helps and that others can help more.
It was a true 64-bit machine. It came out at the time just after the
1st VAX. It was about 2-4 times faster than a VAX (this was 64-bit ops now).
So the philosophical benchmark question is: are you doing twice the work
with a wider word?
Rich got his machine to replace a Cyber 172, and I think they were pretty
happy with him (they needed the numeric precision which 32-bit machines
could not do). I used it once, flew down to EAFB where Dryden is.
I think they sold in the 100s.
Message passing back then was a dirty joke because of DEIMOS.
I think there are other past threads (Deja/google may have them) and
they were a UUCP/Usenet node once they got savvy.
--
Andy Glew
Stephen Fuld
"Eugene Miya" <eug...@cse.ucsc.edu> wrote in message
news:44edd89f$1@darkstar...
snip
> But the problem is gaining acceptance from those who have not had the
> experience. Using the B5K example: I'm not so certain in this day of
> RAM and PRAM models that stacks are relevant any more: HP calculators,
> web browsers, directory stacks in shells, graphics systems, etc.,
> not with standing. Did we really use these because we wanted to (say)
> save memory?
That was one reason. Faster context switches was another. Closeness to the
languages, especially Algol, was then considered desirable to ease
compilation. You have to put yourself in the time period. The things that
we now don't like about stack machines, such as harder to do superscaler,
etc. just weren't issues back then.
I am not saying that anyone should do a stack oriented architecture now, but
it should be studied as an important example of a different way of doing
things.
And, as John pointed out, it has the virtue of surviving when then
competitive machines from companies such as CDC, Honeywell, and NCR didn't.
So they must have done something right, though it could be argued that what
they did right had little to do with their architecture.
> Cray didn't. Was he stupid?
No, of course not. But he was dealing in a market niche where cost wasn't
much of an issue and he sold what, in the hundreds of machines? Burroughs
was selling in far more cost sensitive markets and sold in the thousands or
perhaps even tens of thousands of systems, some quite modest in
size/capacity/cost.
John Mashey
Eugene Miya wrote:
> >Elixi (based in silicon valley) produced a bus based symmetric
> Actually it was an Indian company.
ELXSI was a Silicon Valley company; (large) Indian company Tata was an
investor, and tha name lives on as TATA ELXSI.
At MIPS, we rented time on an ELXSI to run HSPICE to do the R2000, as
it was good at 64-bit scalar floating point.
The ELXSI Wikipedia entry is pretty good, and reminded me that a lot of
interesting people were at ELXSI.
John Mashey
Eugene Miya wrote:
> But the problem is gaining acceptance from those who have not had the
> experience. Using the B5K example: I'm not so certain in this day of
> RAM and PRAM models that stacks are relevant any more: HP calculators,
> web browsers, directory stacks in shells, graphics systems, etc.,
> not with standing. Did we really use these because we wanted to (say)
Well, recall that I proposed this for the following reasons:
"Introduced in *1961*:
1) No assembler, OS (MCP) written in ESPOL (an Algol variant).
2) Efficient support for Algol, including call-by-name (!!), also COBOL
& FORTRAN
3) Multiprocessor.
4) Virtual memory (via segmentation) "
I did *not* propose it because it was a stack machine... but because it
did a lot of things early that many vendors had not achieved even 10
years later.
Note that 2) implies that it could well handle both commercial and
technical workloads, which rare for the time, as most machines were
either character-oriented (and OK for COBOL) or word-oriented (and OK
for FORTRAN). S/360 usually gets the credit for doing both, but the
B5000 was earlier, and although (given Burroughs market), it ended up
in mostly commercial workloads, I heard some liked it due to the
higher-precision FP.
I never used one of these, but had a roommate who did, and had ESPOL
code listings that I looked at (~1970ish). They compared *rather*
favorably with the IBM S/360 OS assembly language code that I worked
with (and I was a serious S/360 assembly programmer at the time). At
the time, many people thought that OSs should be written in assembler,
and some even persisted after UNIX kernel was redone in C.
Eugene Miya
>> experience. Using the B5K example: I'm not so certain in this day of
>> RAM and PRAM models that stacks are relevant any more: HP calculators,
>> web browsers, directory stacks in shells, graphics systems, etc.,
>> not with standing. Did we really use these because we wanted to (say)
>> save memory?
In article <IolHg.298229$mF2.2...@bgtnsc04-news.ops.worldnet.att.net>,
"Stephen Fuld" <s.f...@PleaseRemove.att.net> wrote:
>That was one reason. Faster context switches was another. Closeness to the
>languages, especially Algol, was then considered desirable to ease
>compilation. You have to put yourself in the time period. The things that
>we now don't like about stack machines, such as harder to do superscaler,
>etc. just weren't issues back then.
So like, since I never had a chance to use one: MCP was like EXEC*8
with interactive sessions unlike OS/360 which had to have TSO?
Or just general OS multiprogramming sense of context switching?
>I am not saying that anyone should do a stack oriented architecture now, but
>it should be studied as an important example of a different way of doing
>things.
>
>And, as John pointed out, it has the virtue of surviving when then
>competitive machines from companies such as CDC, Honeywell, and NCR didn't.
>So they must have done something right, though it could be argued that what
>they did right had little to do with their architecture.
Your message raced and beat John's here. FYI.
Well part of the problem is understanding both market size and quality.
CDC didn't have a huge installed base.
>> Cray didn't. Was he stupid?
>
>No, of course not. But he was dealing in a market niche where cost wasn't
>much of an issue and he sold what, in the hundreds of machines? Burroughs
>was selling in far more cost sensitive markets and sold in the thousands or
>perhaps even tens of thousands of systems, some quite modest in
>size/capacity/cost.
Actually not even. I think only YMPs got into the hundreds (and many of
those were actually Supertek designed ELs).
He only sold dozens of a given model. The CHM has a list of mid-90s sites.
Old Systems Guy Mash wrote:
>Well, recall that I proposed this for the following reasons:
>
>"Introduced in *1961*:
>1) No assembler, OS (MCP) written in ESPOL (an Algol variant).
>2) Efficient support for Algol, including call-by-name (!!), also COBOL
>& FORTRAN
>3) Multiprocessor.
>4) Virtual memory (via segmentation) "
Mark, got that?
>I did *not* propose it because it was a stack machine... but because it
>did a lot of things early that many vendors had not achieved even 10
>years later.
I just used that as an example.
>Note that 2) implies that it could well handle both commercial and
>technical workloads, which rare for the time, as most machines were
>either character-oriented (and OK for COBOL) or word-oriented (and OK
>for FORTRAN). S/360 usually gets the credit for doing both, but the
>B5000 was earlier, and although (given Burroughs market), it ended up
>in mostly commercial workloads, I heard some liked it due to the
>higher-precision FP.
IBM has a better marketing and PR organization. ;^)
I've heard the precision argument as well.
>I never used one of these, but had a roommate who did, and had ESPOL
>code listings that I looked at (~1970ish). They compared *rather*
>favorably with the IBM S/360 OS assembly language code that I worked
>with (and I was a serious S/360 assembly programmer at the time). At
>the time, many people thought that OSs should be written in assembler,
>and some even persisted after UNIX kernel was redone in C.
Yeah it will be interesting if Forrest Baskett shows up to the Cray event
on sept. 21. Many people still think assembler is the way to go.
I just came from a packet-switch vs. circuit switch discussion.
But Mark and the group needs to have this depth (and more) on EVERY
architecture suggested and prioritized so that when the reader uses
interest at depth N in the list, the major endorsed points get across
and the remainder can be optional.
--
Eugene Miya
John Mashey <old_sys...@yahoo.com> wrote:
>Eugene Miya wrote:
>> >Elixi (based in silicon valley) produced a bus based symmetric
>> Actually it was an Indian company.
>
>ELXSI was a Silicon Valley company; (large) Indian company Tata was an
>investor, and tha name lives on as TATA ELXSI.
These days, all companies are striving to be multinational.
>At MIPS, we rented time on an ELXSI to run HSPICE to do the R2000, as
>it was good at 64-bit scalar floating point.
>The ELXSI Wikipedia entry is pretty good, and reminded me that a lot of
>interesting people were at ELXSI.
It's a small valley. I wish that we could preserve more of it better.
--
Andrew Reilly
> The List so far isn't merely US Centric. While you and I have posted 2
> German examples most English speakers are not aware, no has even vaguely
> considered computer developments from France (e.g. Lau), Spain, much of
> the rest of Latin America, India (Elxsi was noted and I have run on one)
> but there are other machines there, Japan, or China.
How about this one?
http://www.csiro.au/csiro/content/standard/ps4f,,.html
Apparently it's in a museum somewhere, too.
(Ha! There's a 2nd level .au domain that I didn't know existed. Wonder
how long that's been going?)
Cheers,
--
Andrew
Andrew Reilly
> 2) Efficient support for Algol, including call-by-name (!!), also COBOL
> & FORTRAN
>
> technical workloads, which rare for the time, as most machines were
> either character-oriented (and OK for COBOL) or word-oriented (and OK
> for FORTRAN).
When I was doing undergrad comp-sci, Fortran and Cobol were discussed,
along with their respective strengths and problem domains, but Algol
wasn't. What sort of code did people actually write in Algol? Both
commercial and scientific programs, or just operating system-level code?
Something else? Is there much legacy Algol code that people maintain
Algol compilers to support?
Cheers,
--
Andrew
Stephen Fuld
> "Eugene Miya" <eug...@cse.ucsc.edu> wrote in message
> news:44edd89f$1@darkstar...
>>> But the problem is gaining acceptance from those who have not had the
>>> experience. Using the B5K example: I'm not so certain in this day of
>>> RAM and PRAM models that stacks are relevant any more: HP calculators,
>>> web browsers, directory stacks in shells, graphics systems, etc.,
>>> not with standing. Did we really use these because we wanted to (say)
>>> save memory?
>
>
> In article <IolHg.298229$mF2.2...@bgtnsc04-news.ops.worldnet.att.net>,
> "Stephen Fuld" <s.f...@PleaseRemove.att.net> wrote:
>>That was one reason. Faster context switches was another. Closeness to
>>the
>>languages, especially Algol, was then considered desirable to ease
>>compilation. You have to put yourself in the time period. The things
>>that
>>we now don't like about stack machines, such as harder to do superscaler,
>>etc. just weren't issues back then.
>
> So like, since I never had a chance to use one: MCP was like EXEC*8
> with interactive sessions unlike OS/360 which had to have TSO?
I didn't use one so I can't answer at that level. My knowledge comes from
working on a cache disk system that we adapted to work on Burroughs
equipment and talking with the Burroughs guys we hired to help us with that
"port". But it was, and is, quite different from just about any other
architecture I kbow of, certainly different from Exec-8. See below.
> Or just general OS multiprogramming sense of context switching?
That is what I meant. Since all context was the stack and a couple of
control registers, there was no need to save and restore a whole lot of
registers.
Some big architectural differences between Burroughs large scale system
architecture and most others: (someone who knows Burroughs better than me,
please help out here)
Tagged memory. The memory words had extra, not normally program visible
tags that told what the contents of the memory location was (i.e. integer,
instructions, floating point, etc.)
No separate supervisor mode. All instructions, etc. were nominally
available to any running program, but in practice, only the system type
compilers emited certain instructions. This required a different type of
security where the installation had to specify that a program had the
authority to create instructions that would be executed. I found this most
odd, but it does have certain advantages, such as supervisor calls are not
really context switches, but equivalent to any subroutine calls, just to a
module that was compiled by the "right" program.
MCP, the operating system has some other fairly unique things as well, but
they are less related to the architecture of the system.
Eugene Miya
Andrew Reilly <andrew-...@areilly.bpc-users.org> wrote:
>How about this one?
>http://www.csiro.au/csiro/content/standard/ps4f,,.html
Well I think CSIRO is a fine organization.
That they claim 4: well depends 1,2,3 (DE (Zn), UK, C at BP and E at USA,
the problem being in the number of Zuse machines). All kinds of things
being assembled around that time.
>Apparently it's in a museum somewhere, too.
Well, that's good.
>(Ha! There's a 2nd level .au domain that I didn't know existed. Wonder
>how long that's been going?)
Hmmmm.
--
Eugene Miya
Andrew Reilly <andrew-...@areilly.bpc-users.org> wrote:
>On Thu, 24 Aug 2006 11:56:42 -0700, John Mashey wrote:
>> 2) Efficient support for Algol, including call-by-name (!!), also COBOL
>> & FORTRAN
>> Note that 2) implies that it could well handle both commercial and
>> technical workloads, which rare for the time, as most machines were
>> either character-oriented (and OK for COBOL) or word-oriented (and OK
>> for FORTRAN).
>
>When I was doing undergrad comp-sci, Fortran and Cobol were discussed,
>along with their respective strengths and problem domains, but Algol
>wasn't. What sort of code did people actually write in Algol? Both
>commercial and scientific programs, or just operating system-level code?
>Something else? Is there much legacy Algol code that people maintain
>Algol compilers to support?
The most important thing I think which should be mentioned in the
literature is that the ACM in the early 60s decided to use ALGOL/ALGOL60
as a pseudocode. So CACM papers from that pre-Pascal era still have it.
The Whetstone benchmark is one sample of ALGOL 60 I have MSSed some place.
Dijkstra is claimed to have written business systems and the like.
I really should have look at ALGOL 68 more, but if dreams were horses all
beggars would ride.
ALGOL was also modified, super and subsets into similar languages like
JOVIAL which was a USAF standard for years.
--
Eugene Miya
Stephen Fuld <s.f...@PleaseRemove.att.net> wrote:
>>>> Using the B5K example
>>
>> So like, since I never had a chance to use one: MCP was like EXEC*8
>> with interactive sessions unlike OS/360 which had to have TSO?
>
>I didn't use one so I can't answer at that level. My knowledge comes from
>working on a cache disk system that we adapted to work on Burroughs
>equipment and talking with the Burroughs guys we hired to help us with that
>"port". But it was, and is, quite different from just about any other
>architecture I kbow of, certainly different from Exec-8. See below.
Well, we could troll for the Burroughs guys in comp.sys.unisys,
but I think it's telling that we didn't have a comp.sys.burroughs.
I have awareness of Unix running on BTL Univac 1100 machines.
>> Or just general OS multiprogramming sense of context switching?
>
>That is what I meant. Since all context was the stack and a couple of
>control registers, there was no need to save and restore a whole lot of
>registers.
>
>Some big architectural differences between Burroughs large scale system
>architecture and most others: (someone who knows Burroughs better than me,
>please help out here)
If you want to pursue this, I'll leave the c.s.u cross post.
>Tagged memory. The memory words had extra, not normally program visible
>tags that told what the contents of the memory location was (i.e. integer,
>instructions, floating point, etc.)
I am a little more partial to Burton Smith's Denelcor and Tera work.
But I never had hands on.
>No separate supervisor mode.
>
>MCP, the operating system has some other fairly unique things as well, but
>they are less related to the architecture of the system.
Need more info.
--
John Mashey
Andrew Reilly wrote:
> When I was doing undergrad comp-sci, Fortran and Cobol were discussed,
> along with their respective strengths and problem domains, but Algol
> wasn't. What sort of code did people actually write in Algol? Both
> commercial and scientific programs, or just operating system-level code?
> Something else? Is there much legacy Algol code that people maintain
> Algol compilers to support?
>
> Cheers,
>
> --
> Andrew
Well, there's some long history here, which is reasonably covered in:
http://en.wikipedia.org/wiki/ALGOL
There were hordes of implementations of Algol 58 and Algol 60, and some
of Algol 68, but there were lots of variants, especially since the
earlier ones had no portable I/O, and they usually had their own
names, like MAD (Michigan Algorithm Decoder) or JOIVAL (Jules Own
Version of the International Algebraic Language). All this makes it
hard to say whether there's much "Algol" code left :-)
The language was certainly not particuarly aimed at commercial apps,
but at general & technical algorithms and sometimes systems code. It
was more popular in Europe than in US, but of course, was highly
influential by way of the numerous languages derived from or influenced
by it, i.e., many "modern" languagues look more like Algol than FORTRAN
or COBOL.
So, if you count PL/I as an Algol variant (a stretch, perhaps), there's
still plenty of it.
Perhaps not quite such a stretch is JOVIAL, which was derived from
Algol 58 originally, but is still actively maintained ... because a
great deal of US AIr Force gear still uses it.
Interaction with architecture:
Algol had recursion, which tended to encourage architectures with good
stack-relative addressing or equivalents.
Algol 60 had "call-by-name", which was a bad idea, since it required
the overhead of thunks on most machines. As noted earlier, the B5000
actually supported it in hardware: if you did an "Operand Call" to
fetch an operand and push it onto the stack, one bit in the operand
said whether it was just data, or a descriptor for data, which
automagically invoked a code segment to compute the value and leave the
result on the stack. [This is one of the reasons one would *not*
likely do a B5000 architecture today, since this is a particularly
complex form of indirect addressing - any operand you reference may
dynamically invoke and arbitary next of function calls.]
Doing this on most machines meant that most uses of most function
arguments had to test whether or not an argument was a simple value or
a code descriptor, and in general, the compiled code for a function
couldn't assume that an incoming argument would evaluate to the same
value with every reference. ugh.
Call-by-name generally disappeared from language designs, although
having generated numerous technical papers and a lot of work. This is
one of the most classic examples of something that is overly general,
standardized too early, before there's quite enough experience, and
that had widespread implementation issues.
Jan Vorbrüggen
What's DEIMOS (apart from a moon of Mars)?
Jan
David Hopwood
>> Message passing back then was a dirty joke because of DEIMOS.
>
> What's DEIMOS (apart from a moon of Mars)?
An early OS for the Cray-1. Mentioned briefly at
<http://en.wikipedia.org/wiki/Cray_Time_Sharing_System>.
--
David Hopwood <david.nosp...@blueyonder.co.uk>
Eugene Miya
John Mashey <old_sys...@yahoo.com> wrote:
>So, if you count PL/I as an Algol variant (a stretch, perhaps), there's
>still plenty of it.
I think I attended my first Unix user group meeting before I took a
formal PL survey class (which was also after I sat on an ANSI committee).
The prof found a wonderful cartoon about this:
In a house with a big picture window (very US):
A man, labeled Fortran, was looking at his wife (labeled COBOL), pointing
to his kid, labeled PL/1, saying "He doesn't look like me," with a
milkman outside approaching the house with a delivery and similar facial
features as the kid. The milkman was ALGOL.
I know a lot of Fortran programmers who were really pissed at PL/1.
--
Eugene Miya
Jan Vorbr=FCggen wrote:
>> What's DEIMOS (apart from a moon of Mars)?
In article <SVDHg.163352$F8.1...@fe3.news.blueyonder.co.uk>,
David Hopwood <david.nosp...@blueyonder.co.uk> wrote:
>An early OS for the Cray-1. Mentioned briefly at
><http://en.wikipedia.org/wiki/Cray_Time_Sharing_System>.
DEIMOS was/is praised by OS academics as being ahead of its time
and vilified by the now mostly retired end user physics community
who used Crays as slow and inefficient (due to message passing).
Certain noted CSers who went on to form major research centers and
computer companies and get lots of honors have certainly done well for
themselves where resentful Kings of Science (who also see themselves
as the reason why the Web exists [that pisses Berners-Lee off])
actually actively campaign to kill off computer science research funding.
The reality is that it takes about 10 years to get the major bugs out of
an OS and to tune it for improved performance. Note: words have to be
chosen carefully here.
You can find a nice academic paper in the 1st SOSP proceedings
which may have also been published as a CACM paper.
Nothing like having drunk (and non drunk) physicists make phrases like
"Fucking Unix.... you guys destroyed our work environment...." in your face.
--
John Hudak
me, so I am surprised that the 6809 arn't on the list...not to mention
it was a huge commercial successes.
Jim Haynes wrote:
>>
>>Mark Smotherman wrote:
>>
>>>#1 - admired designs
>>>
>>>
>>>It's been five years since I asked a group of computer
>>>architects about the designs that they admired:
>>>
>>> http://www.cs.clemson.edu/~mark/admired_designs.html
>>>
>>>The list of admired designs is:
>>>
>>> 6502
>>> CDC-6600 and 7600
>>> Cray-1, -2, -4
>>> Cray X-MP and Cray Y-MP
>>> GE-645 (Multics)
>>> IAS
>>> IBM Stretch
>>> IBM 1401
>>> IBM 1570 (not marketed)
>>> IBM 7040 and 7090
>>> IBM S/360 and S/370
>>> IBM S/360 Model 91
>>> IBM ACS
>>> IBM America (RS/6000)
>>> Intel x86
>>> LC-2
>>> MIPS
>>> Multiflow
>>> PDP-11
>>
> I'm amazed by the omission of Burroughs B-5000 and its successors
> from B-6500 on.
pr...@prep.synonet.com
> On Thu, 24 Aug 2006 09:37:23 -0700, Eugene Miya wrote:
>> The List so far isn't merely US Centric. While you and I have posted 2
>> German examples most English speakers are not aware, no has even vaguely
>> considered computer developments from France (e.g. Lau), Spain, much of
>> the rest of Latin America, India (Elxsi was noted and I have run on one)
>> but there are other machines there, Japan, or China.
>
> How about this one?
> http://www.csiro.au/csiro/content/standard/ps4f,,.html
>
> Apparently it's in a museum somewhere, too.
In Melbourne.
> (Ha! There's a 2nd level .au domain that I didn't know existed.
> Wonder how long that's been going?)
A minute less than .edu.au and 1 more than .com.au. edu and csiro
where the original AARNET in 87(?).
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
John Hudak
number)...really bizzar architecture. Its claim to fame was that is was
CMOS (Silicon on Saphire technology), and NASA used it in a number
of satalites and many aerospace companies adopted it in their avionics
boxes. I designed industrial controllers with it....it was UGLY....
John
Edward Feustel wrote:
> "Jim Haynes" <hay...@alumni.uark.edu> wrote in message
> news:v29Fg.7273$Qf....@newsread2.news.pas.earthlink.net...
>>--
>>
>>jhhaynes at earthlink dot net
>>
>
> How about categorizing the architectures for their "breakthrough features"?
> There are some machines with features not in the above list.
>
> 1. Connectivity: the early Thinking Machines (not the CM5), The Transputer
> and connectivity
> chips,
> 2. Protection: Iliffe's BLM, Intel's ill fated projects: 432, and BiiN (960
> XM), the Cambridge CAP Machine,
> 3. Vectors: CDC Star 100, 205
> 4. Message Passing: ELXSI
> 5. Computing in memory: ICL DAP, Goodyear ASP
>
> While it is true that these machines were not commercial successes, it is
> instructive to study them for the ideas that they embodied and to note that
> some of the ideas may be worthwhile pursuing when technology or "societal
> forces" permit/require them.
>
> Ed Feustel
>
>
Eric P.
I never touched one but do have the system architecture and
EMBOS manuals from 1983.
- 1 to 10 processors, 1 to 4 I/O processors, 1 service processor,
up to 193 MB physical RAM connected to a single common bus.
- Each CPU is ECL/LSI 50 ns cycle, microcoded (100 ns for 64 bit ADD)
(Motorola had a bit slice ECL chip set out at that time.
Possibly they used it.)
- CPU Cache: 16 KB 75 ns two way set assoc. 32 B/line
- Each CPU has 16 run contexts, 15 for processes, 1 for "other"
(probably kernel/interrupt)
- Each CPU context: 16 64-bit integer registers, 32 bit virtual space,
16 entry two way assoc. TLB,
byte memory accesses,
16/32/64 bit integer arithmetic,
32/64/80 bit IEEE FPU (used proposed IEEE standard)
- IO Processor: ECL/LSI 50 cycle, two 8 MB/sec sub-busses
- Service processor: M68000
- Backplane: 64 bit + parity (110 bit total), 25 ns cycle, 320 MB/sec
(actual max data rate max = 213 MB/sec)
- Memory: 4...192 MB + ECC, 400 ns DRAM
- Weight: 2500 lb.
The "message passing" consisted of microcoded instructions:
SEND copies a byte buffer to pre-defined system data area,
RECV copies buffer from system area to receive buffer.
I can look up more if you want.
Eric
John Ahlstrom
>> 4. Message Passing: ELXSI
>
> Anyone willing to discuss / present this?
>
> I'vde never really studied ELXSI. Would like to learn.
Anyone care/able to compare and contrast ELXSI with
GEC 4080 message passing?
--
Anne & Lynn Wheeler
> I'm amazed by the omission of Burroughs B-5000 and its successors
> from B-6500 on.
from long ago and far away:
Notes on Alan Kay's Distinguished Lecture at MIT
Dr. Alan Kay, one of the developers of Smalltalk and the Xerox Alto,
and currently a Vice President and Chief Scientist at Atari, gave a
talk at MIT (22 March 1984) titled: "Too many smart people: a personal
view of design in the computer field"
The abstract:
This talk is about the battle between Form and Content in Design and
why "being smart" ususally causes content to lose. "Insightful
laziness" is better because (1) it takes maximum advantage of others
work and (2) it encourages "rotating" the problem into its simplest
essence -- often by changing it completely. In other words: Point of
view is worth 80 IQ points!
... snip ... and ...
Homage was paid to the Burroughs B5000, a computer developed in 1961:
It's operating system was entirely written in a higher level
language (ALGOL)
It had hardware protection (which was later recognized to be
a capability protection system)
It had an object-oriented virtual memory system
It had virtual data
(any data reference could have a procedure attached to it for
fetching and storing the real data--a bit was set as to which
side of the assignment statement it went on)
It was a multiprocessor (it had two processors, and much of the
protection scheme was built in order to allow the two processors
to work together).
It had an integrated stack (which, sadly, is the only thing that
people seem to remember).
"This was twenty years ago! What happened, people?"
The B5000 had some flaws:
The virtual data wasn't done right
there were too many architectural assumptions about physical data
formats
"Char mode: which eliminated all the protections." This was
provided to let programmers used to the 1401 (I think) be
comfortable.
... snip ...
Eric P.
>
> > 4. Message Passing: ELXSI
>
> Anyone willing to discuss / present this?
>
> I'vde never really studied ELXSI. Would like to learn.
The architecture is definitely designed to implement a MACH style
operating system. If fact it can't do anything else:
it has no supervisor mode, no privileged instructions,
no system call instructions. All it has is inter-process messaging,
page sharing via page tables, and interrupt handlers that can execute
when a message arrives in the context of the receiving process.
But first, the visible ISA...
As I said there are 16 hardware contexts, 15 for processes,
one for 'other' (they don't say what, probably the OS kernel).
Each context has:
- 32 bit program counter
- 16 64-bit general registers for 32 bit address, 8/16/32/64 integers,
32/64/80 bit IEEE floats. R15 is the stack pointer.
80 bit floats are stored in a register pair.
- 64 bit Program Status Word (PSW)
Contains Carry bit, Decimal carry bit, floating point round control,
single step trap enable, and a set of exception control bit pairs:
one bit enables, the second indicates exception currently active.
Exceptions are delivered by messages posted back to the process,
which in turn can trigger an interrupt handler routine.
- A 25 nanosecond resolution process real time clock.
Instruction set is variable length and is nicely laid out on 4 bit
boundaries. First 4 bits is the Address Mode (AM), second 4 bits is
the primary opcode (OP1), sometimes third 4 bits is secondary opcode
OP2, sometimes a register. Usually the AM field alone indicates the
instruction length for 'Generalized' formats (whenever OP1 != 0).
Generalized instructions are from 2 to 7 bytes long.
If OP1 == 0 then AM and OP2 give instruction length.
So it looks a very simple decode.
Most instructions have 2 and 3 operand forms. Address mode selects
short or long immediates, or a single memory reference as either an
immediate addresses, register+offset, base+index register + offset.
Data types are: float (32/64/80), integer (8/16/32/64),
logical bit strings (6/16/24/32/40/48/56/64), character, string,
ascii numeric string.
Instructions cover the usual suspects, plus data type conversion, and
byte buffer move, read and write PSW, read process or system real
time clocks. There are also instructions for managing messaging.
Strangely, there are no instructions for the loading or unloading
the hardware process contexts, nor is there any mention of how
this is done. Paging and device interrupts also. There seems to be
quite a lot of the system management that is undocumented. :-(
Eric
Eric P.
>
> > 4. Message Passing: ELXSI
>
> Anyone willing to discuss / present this?
>
> I'vde never really studied ELXSI. Would like to learn.
Now the messaging. Messaging is used for inter-process communication
and exception delivery.
It has 3 structures: links, funnels and channels.
Microcode manages the descriptor tables for each processes'
links, funnels and channels, and message headers and data.
A link is connected to a single funnel and allows a process to send
messages to that funnel. A process can have up to 65535 links
identified by their link id.
A funnel is a mailbox, and can be connected to zero or more links.
One field in the funnel descriptor is a handler address.
This is the address of an interrupt routine that, if enabled,
is called when a message arrives on that funnel, depending on
the current process priority and this funnels' priority.
A channel is a collection of funnels. A process has 16 channels
and each channel can have up to 255 member funnels.
Channels establish interrupt priority for their member funnels.
These messaging interrupt priorities are local to each process
(like VMS AST's but with 16 priority levels).
A message is up to 888 bytes and sent using a specified link
to a funnel. The message is stored in system memory in a linked
list for the funnel and the funnel may trigger an interrupt
depending on the processes' current messaging priority and
the priority of the channel to which the funnel belongs.
When a message interrupt occurs, R15 is used as a stack pointer
to a push down stack to save the current register set and
call the handler. IXIT instruction restores prior state.
A RECV instruction reads the message. It can be either blocking,
waits if no message pending, or non blocking.
There are a variety of instructions for creating, modifying or
deleting each structure or its access rights, and notification
message may be sent to funnels when changes are made.
Basically, it is similar what many other OS's provide, but with
limitations and immortalized in microcode so it cannot be changed.
Eric
Jan Vorbrüggen
> "Fucking Unix.... you guys destroyed our work environment...." in your face.
Well...when you've grown up on TOPS-10 and VMS, I can certainly understand
the sentiment. I certainly thought Unix was a big step back with regard to
useablity, functionality, and security when compared to these and others.
Jan
Jan Vorbrüggen
> number)...really bizzar architecture. Its claim to fame was that is was
> CMOS (Silicon on Saphire technology), and NASA used it in a number of
> satalites
...which also makes it the fastest processor ever developed. It was used,
I believe, on both Voyagers and on Pioneers 10 and 11.
Jan
Nick Maclaren
In article <1156445802.3...@75g2000cwc.googlegroups.com>,
"John Mashey" <old_sys...@yahoo.com> writes:
|> Eugene Miya wrote:
|>
|> > But the problem is gaining acceptance from those who have not had the
|> > experience. Using the B5K example: I'm not so certain in this day of
|> > RAM and PRAM models that stacks are relevant any more: HP calculators,
|> > web browsers, directory stacks in shells, graphics systems, etc.,
|> > not with standing. Did we really use these because we wanted to (say)
|>
|> Well, recall that I proposed this for the following reasons:
|>
|> "Introduced in *1961*:
|> 1) No assembler, OS (MCP) written in ESPOL (an Algol variant).
|> 2) Efficient support for Algol, including call-by-name (!!), also COBOL
|> & FORTRAN
|> 3) Multiprocessor.
|> 4) Virtual memory (via segmentation) "
|>
|> I did *not* propose it because it was a stack machine... but because it
|> did a lot of things early that many vendors had not achieved even 10
|> years later.
One can argue the merits of stack-based designs entirely separately,
and it is worth noting that all of x86, SPARC and IA64 among others
have such elements. Stack-based designs had a nadir in the heyday of
the System/370 (for obvious reasons), but have never gone away entirely.
But you knew that :-)
Regards,
Nick Maclaren.
Nick Maclaren
In article <1156464898....@m79g2000cwm.googlegroups.com>,
"John Mashey" <old_sys...@yahoo.com> writes:
|>
|> There were hordes of implementations of Algol 58 and Algol 60, and some
|> of Algol 68, but there were lots of variants, especially since the
|> earlier ones had no portable I/O, and they usually had their own
|> names, like MAD (Michigan Algorithm Decoder) or JOIVAL (Jules Own
|> Version of the International Algebraic Language). All this makes it
|> hard to say whether there's much "Algol" code left :-)
|>
|> The language was certainly not particuarly aimed at commercial apps,
|> but at general & technical algorithms and sometimes systems code. It
|> was more popular in Europe than in US, but of course, was highly
|> influential by way of the numerous languages derived from or influenced
|> by it, i.e., many "modern" languagues look more like Algol than FORTRAN
|> or COBOL.
|>
|> So, if you count PL/I as an Algol variant (a stretch, perhaps), there's
|> still plenty of it.
Yes and no. There are two aspects.
The EFFECT of Algol 60 was immense - as you say, it is where modern
languages have derived their basic call and control structures from,
but don't forget their syntax descriptions. The effect of Algol 68 was
less, but look at Fortran 90, C++ and others.
Even excluding Burroughs, Algol 60 was used for everything that was done
on a general-purpose system of the 1960s and early 1970s, including
'system' programming and the most commercial of applications. But, as
you say, always in a variant form (see another posting). Algol 68
never took off in the same way, and didn't reach commerce as far as I
know, but was used for at least one production (not commercial) operating
system and quite a lot of scientific code and general-purpose programs.
|> Algol 60 had "call-by-name", which was a bad idea, since it required
|> the overhead of thunks on most machines. ...
|>
|> Call-by-name generally disappeared from language designs, although
|> having generated numerous technical papers and a lot of work. This is
|> one of the most classic examples of something that is overly general,
|> standardized too early, before there's quite enough experience, and
|> that had widespread implementation issues.
Again, yes and no. It's coming back, but THIS time as an explicit option
(which is what it should have been in the first place), and in its Lisp
form and other variants. I quite agree that Algol 60 call by name,
especially as a default, was a disaster - but remember that Algol 60
was not designed for programming in.
Regards,
Nick Maclaren.
Nick Maclaren
In article <44ee38e5$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) writes:
|>
|> The most important thing I think which should be mentioned in the
|> literature is that the ACM in the early 60s decided to use ALGOL/ALGOL60
|> as a pseudocode. So CACM papers from that pre-Pascal era still have it.
That is true, but incomplete. That is PRECISELY what Algol 60 was
designed for - it was never intended for programming in! Its omission
of I/O wasn't a mistake, but was because it wasn't needed for describing
algorithms of the class that Algol 60 was designed to describe. The
authors of the Algol 60 report were caught by surprise when people
actually wrote compilers for it :-)
The same thing happened later with C, when people started to use it for
highly portable and/or highly robust code. It was designed as a semi-
portable assembler, to make writing experimental code fast, and was
(and is) very good for that.
Regards,
Nick Maclaren.
Nick Maclaren
In article <44ef3aa6$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) writes:
|>
|> The reality is that it takes about 10 years to get the major bugs out of
|> an OS and to tune it for improved performance. Note: words have to be
|> chosen carefully here.
As with most large projects, that assumes that the design is one of the
modern type - i.e. bolted together out of a lot of 'neat' ideas, with
only a vague overall design, vague interfaces and no prior validation.
Good, medium-sized operating systems have been developed, debugged and
tuned by small teams in 3-5 years from inception to stability. The
techniques are well-understood, and deeply unfashionable.
Regards,
Nick Maclaren.
Eugene Miya
The Pioneers did not have processors.
Remove them from future thinking of 1802s.
--
Eugene Miya
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>In article <44ef3aa6$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) writes:
>|> The reality is that it takes about 10 years to get the major bugs out of
>|> an OS
>
>tuned by small teams in 3-5 years from inception to stability. The
What's "medium?"
>techniques are well-understood, and deeply unfashionable.
--
Peter "Firefly" Lund
> That is true, but incomplete. That is PRECISELY what Algol 60 was
> designed for - it was never intended for programming in! Its omission
> of I/O wasn't a mistake, but was because it wasn't needed for describing
> algorithms of the class that Algol 60 was designed to describe.
I/O devices were rather varied back then, weren't they?
> The authors of the Algol 60 report were caught by surprise when people
> actually wrote compilers for it :-)
Since the secretary of the Algol 60 committee and main author of the
report on the language, Peter Naur, also was one of the main programmers
of one of the very first compilers for the language (on the
beforementioned GIER), I'd say that this statement is unfounded in the
extreme.
And of course their compiler could do I/O...
-Peter