jdm@a.cs.wvu.wvnet.edu (James D Mooney) (06/14/89)
This is a request for opinions (and an offer of information)
about the Japanese TRON project. As a consultant to
Nippon Telegraph and Telephone for their
work on CTRON (a TRON subproject), I seem to be one of very
few Westerners involved with TRON. Some time ago, in answer
to a question that appeared in comp.arch, I posted some basic
information about TRON. As far as I know, there has been *NO*
further discussion of TRON anywhere on the net. Why not?
For a quick summary, TRON is a project started by Dr. Ken Sakamura
at the U. of Tokyo in 1985, and now being carried on in Japan
by an industrial consortium of over 100 companies. NTT alone
has *hundreds* of people working on it. Most major Japanese computer
companies and Japanese branches of American companies (IBM, HP, etc)
are members. Unlike some other Japanese initiatives it is *not*
government-sponsored.
The goal of TRON is to develop a wide-ranging collection of standards
for use in a very comprehensive distributed network -- one which is
globally connected but involves everything from large hosts to
workstations to a multitude of embedded processors in "intelligent
objects" such as the components of a "smart house." In the TRON
vision, all of these elements could easily communicate, even though
produced by many different manufacturers.
One of the TRON project achievements to date is a standard 32-bit
microprocessor architecture which has been implemented by Hitachi,
Fujitsu, Toshiba, Oki, and others. Other projects which are
already leading to significant products include a new workstation
user interface standard (BTRON) and an operating system interface
for small realtime systems (ITRON). The CTRON project, which I
work on, is developing a comprehensivre operating system interface
standard for larger systems with realtime performance requirements
such as network servers.
Whether the TRON standards are good or bad, the project's scale, and
results to date, make it certain that it will have some impact.
Good descriptions of TRON have appeared in special issues of
IEEE MICRO (April 87, April 88) and in BYTE (April 89). Yet
there seems to be little interest in TRON outside Japan,
at least in the U.S. Now the British Journal Microprocessors and
Microsystems also plans a special issue, and I have been asked to
contribute a short article giving a Western viewpoint
on TRON. What I still don't understand is:
*WHY DOESN'T ANYONE SEEM TO CARE?*
I do have some theories. Which one do you think is right?
1. It's a Japanese project, not relevant outside Japan.
(It is wholly Japanese now, but the industry participation
is comprehensive, association membership is open,
nothing is proprietary, and international participation
has been encouraged for some time.)
2. It's not needed; there are enough standards.
(The areas addressed by many of the TRON projects,
especially realtime systems, have no current standards,
not even de facto ones.)
3. Only single-company de facto standards (like IBM) are practical.
Companies won't cooperate.
(Over a hundred companies in the TRON assoication do not
agree. Several versions of the TRON CPU chip, developed
independently but conforming to the standard, are now on
the market. U.S. projects like POSIX and the Open Software
Foundation show increased concern for open, industry-sponsored
standards.)
4. It's interesting, but will have no effect on me.
(Who among us will not participate in more and more large
scale (and small scale) networking? Does it matter what the
interfaces (of all kinds) are, and what hardware and software
can easily connect?)
5. There's plenty of discussion of TRON outside Japan; you just have
missed it all.
(Please point me in the right direction.)
6. Other?
I welcome all opinions, discussion, or questions. I hope I
have posted this to the most appropriate newsgroups. If there
is any interest, I will be glad to post or mail further information
about TRON, and/or summaries of any comments received. Thanks.
Jim Mooney Dept. of Stat. & Computer Science
(304) 293-3607 West Virginia University
Morgantown, WV 26506
INTERNET: jdm@a.cs.wvu.wvnet.edu
Jim Mooney Dept. of Stat. & Computer Science
(304) 293-3607 West Virginia University
Morgantown, WV 26506
INTERNET: jdm@a.cs.wvu.wvnet.edubaum@Apple.COM (Allen J. Baum) (06/14/89)
[] >In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: > >This is a request for opinions (and an offer of information) >about the Japanese TRON project. >One of the TRON project achievements to date is a standard 32-bit >microprocessor architecture which has been implemented by Hitachi, >Fujitsu, Toshiba, Oki, and others. How about because the TRON hardware architecture is a really ugly CISC architecture which looks worse to build in hardware than the only somewhat ugly CISCs we already have to deal with. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
eugene@eos.UUCP (Eugene Miya) (06/15/89)
In article <32424@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >[] >>In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: >> >>This is a request for opinions (and an offer of information) >How about because the TRON hardware architecture is a really ugly >CISC architecture which looks worse to build in hardware than the >only somewhat ugly CISCs we already have to deal with. The same can also sort of be said about the OS. I have attended two IEEE COMPCON sessions and have scanned the Proceedings as well. There are too many newsgroups on this, so I'm only following up to os.misc. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "You trust the `reply' command with all those different mailers out there?" "If my mail does not reach you, please accept my apology." {ncar,decwrl,hplabs,uunet}!ames!eugene Live free or die.
kevin@LOGICON.ARPA (Kevin McIntyre) (06/15/89)
In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: > > >This is a request for opinions (and an offer of information) >about the Japanese TRON project. As a consultant to >Nippon Telegraph and Telephone for their >work on CTRON (a TRON subproject), I seem to be one of very >... My personal opinion is that it is viewed as a way for Japan to "infiltrate" a portion of the US computer market and then take it over. It's sort of like the car market. They learn from the US on how to do something and then they out do us in the market place. I don't think that the US computer companies want Japan to come up with a better way to do something and then open the doors for them to get into the US market (sort of handing the lynchman the rope to hang you). Of course you could argue that this would "stimulate" the US intellects to do a better job (as in the auto world). I don't knoooooow? Kevin. internet: kevin@logicon.arpa uucp: nosc!logicon.arpa!kevin Of course these are my ideas, no one else can speel this bad.
ked@garnet.berkeley.edu (Earl H. Kinmonth) (06/15/89)
In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: >*WHY DOESN'T ANYONE SEEM TO CARE?* > >I do have some theories. Which one do you think is right? > >1. It's a Japanese project, not relevant outside Japan. It would not surprise me if this is a factor, but I've developed very conflicting impressions of TRON from reading articles in the Nihon keizai shinbun. Some articles have made it out as a UNIX-killer. Everything you always wanted from UNIX plus realtime plus kanji. Others have left me with the impression that it was little more than a knock off on UNIX, designed to get around the charges that accepting UNIX in Japan would be bowing to American software imperialism. Other articles have left me with the impession that it was nothing more than glorified MSX. NOTE: These impressions comes from the Japanese language press. >have posted this to the most appropriate newsgroups. If there >is any interest, I will be glad to post or mail further information >about TRON, and/or summaries of any comments received. Thanks. I'd be interested in any English or Japanese materials you have on the subject. Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary ucbvax!ucdavis!ucdked!cck ehkinmonth@ucdavis
ked@garnet.berkeley.edu (Earl H. Kinmonth) (06/15/89)
In article <456@logicon.arpa> kevin@LOGICON.ARPA (Kevin McIntyre) writes: >In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: >My personal opinion is that it is viewed as a way for Japan to >"infiltrate" a portion of the US computer market and then take it over. Yellow peril in computing, eh what? I've read a fair sprinkling of articles about TRON in Japanese. I've never seen your notion expressed, but there is a Japanese fear of being subject to what some have called "US software imperialism." >It's sort of like the car market. They learn from the US on how to do >something and then they out do us in the market place. I don't think The Japanese automobile industry drew on various sources: domestic, American, European. Overall, they probably learned more from Europe than the US. Look at the early Japanese models. You see far more European and Japanese engineering than you do GM Rocket 88 Dynaflow super V8, 4 mpg, design. >that the US computer companies want Japan to come up with a better way >to do something and then open the doors for them to get into the US >market (sort of handing the lynchman the rope to hang you). To change metaphors a bit -- if you sit around jerking off and your competition spends their time pumping iron, guess who ends up with the muscles? >Of course you could argue that this would "stimulate" the US intellects >to do a better job (as in the auto world). Or to raise prices under a quota system. >Of course these are my ideas, no one else can speel this bad. Let's hope not.
pl@etana.tut.fi (Lehtinen Pertti) (06/15/89)
From article <382@h.cs.wvu.wvnet.edu>, by jdm@a.cs.wvu.wvnet.edu (James D Mooney): > > *WHY DOESN'T ANYONE SEEM TO CARE?* > > I do have some theories. Which one do you think is right? > > 1. It's a Japanese project, not relevant outside Japan. > With this (as well as other "foreign processors") we can see old words: "It's outside US, it threatens us" or "It's outside US, it's not serious, propably some student project" We saw ARM dropped out from RISC list, although it's first commercial RISC. TRON is forgotten. Have you heard about Philips 68070, or Hitachi H-series? Is transputer known to You? -- pl@tut.fi ! All opinions expressed above are Pertti Lehtinen ! purely offending and in subject Tampere University of Technology ! to change without any further Software Systems Laboratory ! notice
hankd@pur-ee.UUCP (Hank Dietz) (06/15/89)
>From article <382@h.cs.wvu.wvnet.edu>, by jdm@a.cs.wvu.wvnet.edu (James D Mooney): > *WHY DOESN'T ANYONE SEEM TO CARE?* I've said this privately... what the heck, I'll say it in public 8-). The Japanese blew most of their credibility in this field with the Fifth Generation campaign; most of us took that very seriously and then found very little significant in it. TRON seems to be much the same -- we hear lots of vague hints of greatness and then see nothing much of worth. There is also the fact that US participation isn't welcome in the developement phase.... -hankd@ee.ecn.purdue.edu
peter@ficc.uu.net (Peter da Silva) (06/15/89)
In article <382@h.cs.wvu.wvnet.edu>, jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: > *WHY DOESN'T ANYONE SEEM TO CARE?* > I do have some theories. Which one do you think is right? > 1. It's a Japanese project, not relevant outside Japan. I think that's a relevant factor, but it's not the whole story by any means. Japan Incs "we will bury you" attitude with the 5th generation project really doesn't help any, either. > 2. It's not needed; there are enough standards. That depends on the area. I think people in the US *are* getting tired of standards... there are so many of them. Maybe there's a bit of baby-and- bathwater stuff going on here. But just a bit. > 3. Only single-company de facto standards (like IBM) are practical. > Companies won't cooperate. This is a good point. Not only don't companies tend to co-operate, but in the US there are laws that restrict companies from co-operating. > 4. It's interesting, but will have no effect on me. this is basically a corrolary to #1 and #2. > 5. There's plenty of discussion of TRON outside Japan; you just have > missed it all. :-> > 6. Other? For me, here's the main reason: it completely ignores the standards work that *has* been going on in the US. Basically, no part of TRON is based in any way on the UNIX system call interface. What I've heard of it bears a strong resemblance to the messed-up massive-shared-library interfaces common to both '60s operating systems and (more recently) things like OS/2 and X. And, at least in the US, it doesn't have either a 500-pound-gorilla (IBM) or the virtue of public domain status (thanks to the X consortium) behind it. Speaking of design-by-comittee: what's the status of ADA in Japan? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
meo@stiatl.UUCP (Miles O'Neal) (06/15/89)
In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: ... | Whether the TRON standards are good or bad, the project's scale, and | results to date, make it certain that it will have some impact. ... | *WHY DOESN'T ANYONE SEEM TO CARE?* | | I do have some theories. Which one do you think is right? | | 1. It's a Japanese project, not relevant outside Japan. Bingo. There's a lot of shortsightedness, NIH syndrome, and similar stuff around. | 2. It's not needed; there are enough standards. Possibly. | 3. Only single-company de facto standards (like IBM) are practical. I doubt this is a biggie. | 4. It's interesting, but will have no effect on me. Bingo again. Japanese project, Japanese standard. Part of it is, I believe, frustration and fear of the Japanese, and lack of any clear idea how to deal with them. SO, in typical US fashion, we ignore it and hope it goes away. But also, there has not been very much press coverage, or professional group attention turned towards it. I suspect most of us don't really even know what all it covers. I certainly don't. Throw in that with the fact that we are standardizing on UNIX (the ultimate real-time system (haha)) and a handful of microprocessors, and most people see no need, no interest, no threat. SO, educate us. What are the high points, the low points, and such, from your vantage point? -Miles
weh@sei.cmu.edu (Bill Hefley) (06/15/89)
In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: > > >This is a request for opinions (and an offer of information) >about the Japanese TRON project. As a consultant to >Nippon Telegraph and Telephone for their >work on CTRON (a TRON subproject), I seem to be one of very >few Westerners involved with TRON. Some time ago, in answer >to a question that appeared in comp.arch, I posted some basic >information about TRON. As far as I know, there has been *NO* >further discussion of TRON anywhere on the net. Why not? > I, for one, have been interested in what was happening with this effort, especially BTRON because of my background in designing computer-human interfaces for large-scale (near-) real-time systems. But, other than the minimal articles that you've mentioned, I've seen very little in the way of papers presented or short news articles in the appropriate trade press. I've seen little in the way of announcing the means for participation or obtaining these "standards" that were mentioned. This is often true of many standards efforts, especially volunteer efforts, but until people find out more about the efforts, interest will continue to be low, I would expect. In many ways, this is the classical chicken and egg technology transfer problem. ____ ______ _____ _____===== Bill Hefley / __ \ | _____| |_ _| _____========= Software Engrg Institute | |__|_| | |__ | | _____============= Carnegie Mellon _\___ \ | __| | | _____================= Pittsburgh, PA 15213 | |__| | | |____ _| |_ _____============= (412) 268-7793 \____/ |______| |_____| _____========= ARPA: weh@sei.cmu.edu -----===== BITNET: weh%sei.cmu.edu CSNET: weh%sei.cmu.edu@ relay.cs.net C a r n e g i e M e l l o n U n i v e r s i t y +---------------------------- Disclaimer -------------------------------+ | The views expressed herein are my own and do not necessarily reflect | | those of my employer. | +-----------------------------------------------------------------------+
pms@vicorp.UUCP (Peter Shirley) (06/16/89)
Well, I haven't been discussing TRON because this is the first I've heard of it. I'm interested, particularly in what commercial applications we're likely to see first in the US (since I'm less likely to be able to see and try things that exist only in other countries), and also in what neat new stuff the TRON project is doing. It sounds like the project is far too big for anything more than a brief overview in this newsgroup, but could you direct me (and others) to a source (or sources) of detailed information about TRON, both in terms of its objectives (which I'm sure I can glean from the magazine articles) and its current (and ongoing) status? -Peter
mslater@cup.portal.com (Michael Z Slater) (06/16/89)
> Why is there little apparent interest in TRON?
The manufacturers are all Japanese, and have not promoted TRON in the US.
As far as I can tell, they don't intend to do so, and US distribution is
likely to be slim or nonexistent.
Also, as Alan Baum has pointed out, the TRON architecture is considered to
be very slow for the amount of silicon it requires. Designers today look
at the 680x0 or 80x86 if they want binary compatibility with existing
software, and at RISC processors if they want optimum price/performance.
I don't see what the motivation would be to look at TRON.
Michael Slater, Microprocessor Reporteugene@eos.UUCP (Eugene Miya) (06/16/89)
In article <5117@stiatl.UUCP> meo@stiatl.UUCP (Miles O'Neal) writes: >In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: >| 1. It's a Japanese project, not relevant outside Japan. >Bingo. There's a lot of shortsightedness, NIH syndrome, and similar stuff >around. >| 2. It's not needed; there are enough standards. >Possibly. >| 3. Only single-company de facto standards (like IBM) are practical. >I doubt this is a biggie. >| 4. It's interesting, but will have no effect on me. >Bingo again. Japanese project, Japanese standard. > >Part of it is, I believe, frustration and fear of the Japanese, and >lack of any clear idea how to deal with them. SO, in typical US fashion, >we ignore it and hope it goes away. > >But also, there has not been very much press coverage, or professional >group attention turned towards it. I suspect most of us don't really >even know what all it covers. I certainly don't. Throw in that with the >fact that we are standardizing on UNIX (the ultimate real-time system >(haha)) and a handful of microprocessors, and most people see no need, >no interest, no threat. > >SO, educate us. What are the high points, the low points, and such, >from your vantage point? Go find the last two years IEEE COMPCON proceedings. Each has had an entire session on TRON. There are also the occasional articles in IEEE Computer. More details than can be posted. You should be aware that the Usenet is being read in Japan. It's readership is impressive and growing. I had this made clear to me in recent meetings. Theirs is a culture which takes a much different view to electronic mail and news than we do. You will not see many postings because to express one's opinion means to carry great weight (unlike here). So if you (general readership) care to insult them, they will read it. You will just be ignored as a crank. I think some grave mistakes (or absolutely brilliant, but off the wall decisions) in choice were made. I follow the TRs and TNs which come from places like ICOT, various companies, etc. So you see this note "tips my hand." Like the early selection of IBM compatable supercomputers is one decision [long before the 3090 mainframe line]. This goes for so-called new-generation machines (a physicist here believes the NeXT is the first real 5th gen. machine). Prolog engines, inference machines, etc. Different choices. It permeates decisions in areas like software or architectures. It is interesting to compare my non-disclosure 1990-notes of 1984 to the latest architectures from the one particular conglomerate. Plans have clearly changed. Workstations and Unix are coming in. Watch for hypercubes or Connection Machine-like architectures. If one appears, our "lead" will diminish even more. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "You trust the `reply' command with all those different mailers out there?" "If my mail does not reach you, please accept my apology." {ncar,decwrl,hplabs,uunet}!ames!eugene Live free or die.
ked@garnet.berkeley.edu (Earl H. Kinmonth) (06/16/89)
In article <4567@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <382@h.cs.wvu.wvnet.edu>, jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: >> *WHY DOESN'T ANYONE SEEM TO CARE?* > >> I do have some theories. Which one do you think is right? > >> 1. It's a Japanese project, not relevant outside Japan. > >I think that's a relevant factor, but it's not the whole story by any means. > >Japan Incs "we will bury you" attitude with the 5th generation project really >doesn't help any, either. The "we will bury you" attitude, if it ever existed, was a figment of Feigenbaum's (or that air-head female collaborator's) imagination. The Japanese are hardly above criticism, but they don't deserve to be blamed for the machinations of an academic scam artist like Feigenbaum. >> 2. It's not needed; there are enough standards. > >That depends on the area. I think people in the US *are* getting tired of >standards... there are so many of them. Maybe there's a bit of baby-and- >bathwater stuff going on here. But just a bit. Maybe the hackers and the adepts are getting tired of standards because standards decrease the demand for the services of high priced anal retentives who get off on knowing the arbitrary and often assine distinctions between various systems, releases, etc. I've not seen any evidence that ordinary users or corporate purchasers are tired of standards. > >> 3. Only single-company de facto standards (like IBM) are practical. >> Companies won't cooperate. > >This is a good point. Not only don't companies tend to co-operate, but >in the US there are laws that restrict companies from co-operating. Apparently you haven't been reading either the (computer) trade papers or such general items as the Wall Street Journal, the New York Times, etc. As part of an attempt to meet Japanese competition (real or imagined) by using Japanese techniques (real or imagined), the RayGun/Bush administrations and the Justice Department have been encouraging "corporate research cooperation" by a variety of means: interpretation of anti-trust laws, specific legislation, subsidies, etc. The historical fact that ~American~ companies have not chosen to cooperate on basic research does not in and of itself determine what is efficient, morally correct, or whatever. For better or worse, the day when American patterns would be assumed to be best is rapidly waning. (This is not to say that Japanese patterns are better. Rather, there are more heavy weights in the ring today than there were a couple of decades ago. US firms cannot assume that American ways are automatically the best the way they could and did through most of the post world war II period.) >> 4. It's interesting, but will have no effect on me. This sounds rather like Detroit's observations concerning Japanese automobile engineering in the 1960s. It would be naive to assume that history will repeat itself in computing; it would be equally navie to assume that it will not. >For me, here's the main reason: it completely ignores the standards >work that *has* been going on in the US. Basically, no part of TRON is >based in any way on the UNIX system call interface. What I've heard of >it bears a strong resemblance to the messed-up massive-shared-library >interfaces common to both '60s operating systems and (more recently) >things like OS/2 and X. And, at least in the US, it doesn't have either >a 500-pound-gorilla (IBM) or the virtue of public domain status (thanks >to the X consortium) behind it. Here, I think you're on reasonably solid ground, but I'm not sure this is the basis for writing off Japanese efforts. Although my period of specialization is Japanese history of the 1930s and 1940s, I've read enough of the 1950s and 1960s to have some sense of how Japanese firms have operated. Following obsolete or unproductive American || European lines has actually been fairly common in industries that later became successful. To a degree Japanese firms seem to learn from this process or are driven to make breakthroughs by the frustation of trying to develop what they thought were good (foreign) ideas. False starts, dead ends, and general confusion have been a large part of Japanese efforts in other areas. They may fall flat on TRON, but I would not be banking that a failure on this project will set the pattern for everything the Japanese do in this area.
khb@chiba.Sun.COM (chiba) (06/16/89)
In article <5117@stiatl.UUCP> meo@stiatl.UUCP (Miles O'Neal) writes: > >SO, educate us. What are the high points, the low points, and such, >from your vantage point? > The other night CNN had a 5+ minute story on TRON. They reported that the TRONgroup (whatever it is officially called) included several European vendors, and they went into some depth on a project to build a "smart house" with about 10,000 microprocessors (mostly 8-bit it seemed). In addition to the smart house, there was a smart office complex underway. The "big wins" from having fully enlightened and mutually comunicating applicances was that turning up the stereo would close the windows, turn up the air conditioning, get turned down by the phone, etc. In addition, turning on a light would result in more air conditioning. The guiding principal was supposed to make life better and easier; every design decision is supposed to be made from the user perspective ... While CNN is most certainly not the best sort of medium for a technical exposition, it seemed that the goals (or examples thereof) could possibly justify the expensive of the massive wiring harness (which they showed), the decreased reliabilty (I cannot see how connecting my toaster and microwave to my reading light can _increase_ reliability of the system) and general increase in complexity. In addition, the stated plan was to start with a sample house and office bldg; work up to a city (big brother watches each toliet flush, and reacts accordingly) then to a province (chiba ?) then to all Japan, then to all the world .... While this is probably a good warm up for building a large multi-generation spaceship, the vision of a vast number of Z80's communicating with some Fifth Generation Supercomputer with the big payoff being that my heating and airconditioning might be 5% more efficient (somehow having a few more thermostats didn't seem to occur to them) does not seem all that interesting. The TRON keyboard (very post dvorak), the communication protocols, and many of the other subprojects are probably quite interesting. But the fundamental mindset (presumning the CNN staff was doing due dilligence ... which is admittedly uncertain) seems wrong ... having appliances talk to each other, across the world does not automatically make sense. I am hoping that one of you NetLanders can enlighten me ... why are the TRONfolks working so hard ... what are the problems they are trying to solve. Until these are clearly articulated, arguments about how many wires are needed to build a robust applicance communications channel seem moot. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
exiphm@eutrc3.UUCP (h.munk) (06/16/89)
... [mail] [mail] [mail] ... In article <11948@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes: > >From article <382@h.cs.wvu.wvnet.edu>, by jdm@a.cs.wvu.wvnet.edu (James D Mooney): > > *WHY DOESN'T ANYONE SEEM TO CARE?* > > I've said this privately... what the heck, I'll say it in ... [more mail] [more mail] [more mail] ... Ok, folks. Let's get back to computer architecture, please ?
charette@edsews.EDS.COM (Mark A. Charette) (06/16/89)
In article <382@h.cs.wvu.wvnet.edu>, jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: > > > The goal of TRON is to develop a wide-ranging collection of standards > for use in a very comprehensive distributed network -- one which is > globally connected but involves everything from large hosts to > workstations to a multitude of embedded processors in "intelligent > objects" such as the components of a "smart house." In the TRON > vision, all of these elements could easily communicate, even though > produced by many different manufacturers. > One aspect of this, the communications between the processors, has me worried somewhat. When I read some reports on TRON (which are not handy at the moment), I noticed that the intent was for all processors on the TRON network to have the ability to communicate. The `smartness' intended for the TRON network could be subverted to governmental or criminal misuse very easily. Remember, just using a credit card in stores today with card readers could let someone (with intents other than making sure your credit limit hasn't been exceeded) know where you are and what you're doing. -- Mark Charette "People only like me when I'm dumb!", he said. Electronic Data Systems "I like you a lot." was the reply. 750 Tower Drive Voice: (313)265-7006 FAX: (313)265-5770 Troy, MI 48007-7019 charette@edsews.eds.com uunet!edsews!charette
ked@garnet.berkeley.edu (Earl H. Kinmonth) (06/16/89)
In article <110573@sun.Eng.Sun.COM> khb@sun.UUCP (chiba) writes: >In article <5117@stiatl.UUCP> meo@stiatl.UUCP (Miles O'Neal) writes: >> >>SO, educate us. What are the high points, the low points, and such, >>from your vantage point? >> > >The other night CNN had a 5+ minute story on TRON. They reported that the Any CNN coverage on Japan is suspect. Not only does it suffer from the usual American problem of illiterates (in Japanese) reporting on a culture they know little about, there is the special problem that some of CNN coverage on Japan is funded by Sasagawa Ryoichi, an extreme right winger who controls betting on boat racing in Japan. >office bldg; work up to a city (big brother watches each toliet flush, >and reacts accordingly) then to a province (chiba ?) then to all >Japan, then to all the world .... This should be easy to accomplish in Japan. Microprocessor pot seats have been big in Japan for a number of years (I kid you not). You can easily spend $2500 on a pot. These include not just a heated seat (bun warmer) but various scented air and water sprays. Some have sensors to tell you your body temparature, pulse and blood pressure. (How representative measures are when you're taking a shit is open to question.) I got my (Japanese) wife to test fly one set up in the women's head of the Nada-Kobe Coop near our home. She said there were so many controls and options that she finished her business before she could figure out how to programme the pot. Once she had, she decided she wasn't going to let a microprocessor decide what got sprayed on her privates!
peter@ficc.uu.net (Peter da Silva) (06/17/89)
In article <25518@agate.BERKELEY.EDU>, ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: > Maybe the hackers and the adepts are getting tired of standards because > standards decrease the demand for the services of high priced anal > retentives who get off on knowing the arbitrary and often assine > distinctions between various systems, releases, etc. We're getting a bit hot under the collar here, aren't we? I'm not talking about SysVr3.2.9u.16b-7 versus SysVr3.2.9u.27-alpha. I'm talking about SAA versus AIX/OSF versus AT&T, or Display Postscript versus NeWS versus X. Where you have several competing standards that aren't going to combine into anything good. TRON, from here, just looks like more of the same. > I've not seen any > evidence that ordinary users or corporate purchasers are tired of > standards. I don't think that ordinary users care about the technical merits of AIX versus SysV.3.2. But they're both bases for opposing standards. > the RayGun/Bush administrations and the Justice Department have been > encouraging "corporate research cooperation" by a variety of means: > interpretation of anti-trust laws, specific legislation, subsidies, > etc. That's nice, but the laws are still on the books. And as S&Ls are learning, dead administrations don't keep promises very well. Now if Congress should step in... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
gld@CUNIXD.CC.COLUMBIA.EDU (Gary L Dare) (06/17/89)
In article <4567@ficc.uu.net> Peter da Silva wrote: >In article <382@h.cs.wvu.wvnet.edu>, James D Mooney writes: > >> 3. Only single-company de facto standards (like IBM) are practical. >> Companies won't cooperate. > >This is a good point. Not only don't companies tend to co-operate, but >in the US there are laws that restrict companies from co-operating. What is interesting is that US companies aren't piping this work into their European and Canadian arms, since cooperation can take place there. That should side-step the American monopoly restrictions. We have a "Combines Act" in Canada, but that only pertains to activity in the market; research is exempt. However, the over-riding unwillingness to cooperate in the home office is probably a large reason why the Allied advantage is not being taken advantage of. gld -- ~~~~~~~~~~~~~~~~~~~~~~~~ je me souviens ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gary L. Dare > gld@eevlsi.ee.columbia.EDU "Roll Over Khomeini - > gld@cunixd.cc.columbia.EDU and tell Pahlavi the news!" > gld@cunixc.BITNET
jdm@a.cs.wvu.wvnet.edu (James D Mooney) (06/17/89)
I got an earful. Obviously, some people do have opinions on TRON. I will post a summary soon. Some inquiries asked for more information. I am posting an overview of current TRON information as I know it. I hope this answers most questions. This overview includes a bibliography, and I will try to keep it up to date. I posted the initial query to five newsgroups, but discussion probably shouldn't continue to be duplicated on all five. Maybe someday there should be a TRON newsgroup. Meanwhile I will try to confine the discussion to comp.misc. Jim Mooney Dept. of Stat. & Computer Science (304) 293-3607 West Virginia University Morgantown, WV 26506 INTERNET: jdm@a.cs.wvu.wvnet.edu
news@ism780c.isc.com (News system) (06/17/89)
In article <5117@stiatl.UUCP> meo@stiatl.UUCP (Miles O'Neal) writes: >But also, there has not been very much press coverage, or professional >group attention turned towards it. I suspect most of us don't really >even know what all it covers. I certainly don't. Throw in that with the >fact that we are standardizing on UNIX (the ultimate real-time system >(haha)) and a handful of microprocessors, and most people see no need, >no interest, no threat. > >SO, educate us. What are the high points, the low points, and such, >from your vantage point? We are just finishing a Unix port to the H32/200 one of the chips in the TRON family. What I can tell you is that it is the ULTIMATE CISC machine. Here is a single assembly source instruction: mov @(@(@(@(100000,r1),300000,r2),400000,r3),500000,r4),\ @(@(@(@(100000,r1),300000,r2),400000,r3),500000,r4) And here is the resulting object instruction. D20B 4412 0001 86A0 4812 0004 93E0 4C12 0006 1A80 9012 0007 A120 8A0B 4412 0001 86A0 4812 0004 93E0 4C12 0006 1A80 9012 0007 A120 This single instruction perfoms 8 memory accesses for address computation and two more accesses to move data. And it is possible to write an instruction even longer than this one. Needless to say, the compiler that I wrote does not make use of all the possible address modes. Marv Rubinstein
roger@wraxall.inmos.co.uk (Roger Shepherd) (06/19/89)
In article <5117@inmos.co.uk (Miles O'Neal) writes: >In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: >| *WHY DOESN'T ANYONE SEEM TO CARE?* >Bingo. There's a lot of shortsightedness, NIH syndrome, and similar stuff >around. ================================================= > > Throw in that with the >fact that we are standardizing on UNIX (the ultimate real-time system ====================== This reminds me of Britains big push in transportation in the 1930s. We widened some of our canals - the Germans built the autobahns! Roger Shepherd, INMOS Ltd JANET: roger@uk.co.inmos 1000 Aztec West UUCP: ukc!inmos!roger or uunet!inmos-c!roger Almondsbury INTERNET: @col.hp.com:roger@inmos-c +44 454 616616 ROW: roger@inmos.co.uk
kennel@mickey.cognet.ucla.edu (Matthew Kennel) (06/21/89)
In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: > >[The Japanese will be taking over with TRON] > >*WHY DOESN'T ANYONE SEEM TO CARE?* > >I do have some theories. Which one do you think is right? > >1. It's a Japanese project, not relevant outside Japan. > But it seems obvious that the Japanese will dominate this segment---why should US concerns give them any more of a head start than they already have? Who wants to be in the "fourth string" behind Fujitsu, NEC and Hitachi? > >6. Other? > Maybe the TRON CPU chip sucks? >Jim Mooney Dept. of Stat. & Computer Science >(304) 293-3607 West Virginia University > Morgantown, WV 26506 Matt Kennel
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (06/21/89)
The June 89 IEEE Micro is a "special Far East issue" edited by Ken Sakamura, with the lead articles devoted to TRON subjects. Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
chimiak@umbc3.UMBC.EDU (Dr. William Chimiak) (06/23/89)
Could it be that Japan hopes to develop adequate software and hardware for a domestic market they have targetted? Now that they have a standard that the US cares nothing about, those machines (no matter how inferior or superior) are national standards for a selected market. They have a hammerlock on the their market and they still support popular non-Japanese systems for foreign sales and have a clever impediment to foreign sales. In addition, if TRON meets design goals, then they will storm foreign markets.
diamond@diamond.csl.sony.junet (Norman Diamond) (06/26/89)
*** comp.realtime has been removed from this follow-up because our news system doesn't know that newsgroup. That is unfortunate; comp.realtime would have been more appropriate than the remaining cross-posted groups. In article <2140@umbc3.UMBC.EDU> chimiakb@mmlai.uu.net. (Dr. William Chimiak) writes: >Could it be that Japan hopes to develop adequate software and hardware >for a domestic market they have targetted? You mean like the U.S.A. has done? Blocking better OS's from some American vendors? >Now that they have a standard that the US cares nothing about, That is the U.S.A.'s problem. Japan cares something about American operating systems, including inferior ones. >those machines (no matter how >inferior or superior) are national standards for a selected market. Just like the U.S.A. did. >They have a hammerlock on the their market TRON will be public domain, unlike any U.S. operating system that I am aware of. Any serious U.S. company that is not preparing their TRON OS now is rather foolish. >and they still support popular non-Japanese systems for foreign sales Yes, and the U.S.A. should learn to support popular non-American systems. >and have a clever >impediment to foreign sales. In addition, if TRON meets design goals, >then they will storm foreign markets. Again, any serious U.S. company that is not preparing their TRON OS now, even for their home market, is rather foolish. *** There are reasons to be critical of TRON (several of its aspects anyway), but Dr. Chimiak's posting did not cite any valid ones. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are claimed by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo, Stanford, or Anterior, then their administrators must have approved of these opinions.
jdm@a.cs.wvu.wvnet.edu (James D Mooney) (07/05/89)
I have been following with great interest the continuing discussion on TRON, although I have been away for the last ten days. Thanks to all who posted comments or provided them by mail. I have tried to reply to any questions, and will continue to do so. A summary will be posted shortly. I have sent copies of the comments to the TRON Association. Dr. Ken Sakamura, TRON Project Leader, has asked me to post the following response. The message from Dr. Sakamura included the following header lines: --From: Ken SAKAMURA <a36773%tansei.cc.u-tokyo.ac.jp@RELAY.CS.NET> --Return-Path: <a36773@tansei.cc.u-tokyo.junet> I am no expert on e-mail addresses, especially to Japan, but anyone wishing to reply directly to Dr. Sakamura could try these addresses. Alternately, send your reply to me and I will forward it somehow. MESSAGE FROM DR. KEN SAKAMURA: ----------------------------------------------------------------- Dear Colleagues, I understand that Dr. Mooney's questionnaire produced a flurry of postings on the TRON project. As the leader of the project, I am delighted to hear frank opinions on the project from many people. However, I also noticed that the TRON project is not widely known at least in the USA. If you can spare some time, reading the following articles/books gets you enough knowledge to discuss the topics on the TRON project in a constructive mannner. Sakamura, Ken (ed). IEEE MICRO Special issue on TRON. Vol 7, No. 2, April 1987. Sakamura, Ken (ed.) TRON Project 1987: Open-Architecture Computer Systems (Proceedings of the Third TRON Project Symposium) Springer-Verlag, Tokyo, 1987 Sakamura, Ken (ed.) IEEE MICRO special issue on the 32-Bit Microprocessor in Japan. Vol. 8, No. 2, April 1988. Sakamura, Ken (ed.) TRON Project 1988: Open-Architecture Computer Systems (Proceedings of the Fifth TRON Project Symposium) Springer-Verlag, Tokyo, 1988 Sakamura, Ken, and Sprague, Richard. The TRON Project. BYTE, Vol 14, No. 4, April 1989, pp. 292-301. Sakamura, Ken (ed) IEEE MICRO Special Far East issue. Vol. 9, No. 3, June 1989. I understand that our efforts to publicize the result of the TRON project leave much to be desired. Also detailed specifications are made available only after they reach the final stage of design. During the design phase, the members of the TRON associations are the ones who discusses the pros and cons of the intermediate designs. Since there are more than 100 companies including companies from the U.S.A., our efforts to disseminate the information are focused to the members of the TRON Association. I understand that there are many opinions as to the details of the specifications. We already have a diversity of opinions from the TRON association memebers. Let me just point out that one of the major targets of the TRON project is to standardize computer interfaces of the electronic appliances that have much influence on our everyday life. I can't speak for the U.S.A., but at least in Japan many home appliances have built-in microprocessors, and the trend to incoporate computers will continue. The power of microprocessors makes home appliances perform many fancy things, but some of these become too difficult for ordinary men and women to use. The best way to solve this problem is to let the computers offer better human-machine interfaces. Of course, we don't want to use additional separate computers, but the built-in computers should support such interfaces. Such interfaces must handle somewhat complex operations other than simple turning on/off switches. Standardization of such interfaces is the only way to have a comprehensive home automation that allows us to use many computer-controlled objects in a harmonious way. Regarding the large number of wires in the TRON house reported in a segment of the CNN program, I should mention that the TRON house reported is an experimental one and we intentionally incoporated many wires that should have been invisible. (We will use better technology to route sensor signals, and other control signals in real TRON houses in the future.) That is why there are so many visible wires today in the TRON house. It is certainly shocking, isn't it? By the way, the enhanced capability of the home appliances and houses are not meant to improve the conditions of people in general only. We have already paid close attention to the way these computer controlled objects may help the handicapped and the old. Such considerations are very important when the birth rate in industrialized countries has begun dropping. My guess is that the first encounter of many people in the U.S.A with products based on the TRON specification will be in the home, through computer-controlled home appliances. Regards, Ken Sakamura. ____________________________________ END OF MESSAGE FROM DR. KEN SAKAMURA Jim Mooney Dept. of Stat. & Computer Science (304) 293-3607 West Virginia University Morgantown, WV 26506 INTERNET: jdm@a.cs.wvu.wvnet.edu
alan@oz.nm.paradyne.com (Alan Lovejoy) (07/06/89)
The recent postings on TRON have spurred me to investigate the subject. My conclusion so far is that the purpose of the TRON project is to build an infrastructure for domestic computerization/automation. Sociocultural implications aside, the major impact of this effort is likely to be that Japanese companies will vastly strengthen their already impressive domination of the consumer appliance market by means of TRON. TRON's technical merits (or lack thereof) will simply be irrelevant. The first economically-viable infrastructure will always swamp any and all competition. It also occurs to me that there are other areas where effective application of technology in the economy awaits the construction of the appropriate infrastructure. And in many of these cases, no planned or purposeful programs are underway to create those infrastructures. There are opportunities here for clever, resourcefull people. Opportunities that I am convinced American companies are largely missing out on--and in fact may be culturally incapable of exploiting or even recognizing. Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me. ______________________________Down with Li Peng!________________________________ Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.
uri@arnor.UUCP (Uri Blumenthal) (07/06/89)
From article <32424@apple.Apple.COM>, by baum@Apple.COM (Allen J. Baum): > How about because the TRON hardware architecture is a really ugly > CISC architecture which looks worse to build in hardware than the > only somewhat ugly CISCs we already have to deal with. > Sorry, but I don't remember such terminology in Computer Science - ugly, nice, beautiful... More specific, please? Efficiency, performance, instruction set (oh, it's CICS, but you probably know how WIDE this term is now, don't you), features? Is it something like iAPX-432 (I mean - ideas)? Thanks. Uri. P.S. Don't waste time flaming me - I'd rather like a technical answer.
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/07/89)
[various comments on the momentous significance of TRON.] My specialty is Japanese history. I cannot claim any particular expertise on TRON. As an historian with some interest in Japanese science and technology, I can say Japanese are capable of matching Americans in hyperbole and boondogles. All of the grantsmanship games known in the US are also known in Japan and then some. TRON may be hype. It may be substance. It may be a mix (the most probable case). In any event, readers should not let the overall reputation of Japanese technology determine their evaluation of TRON. Nor should they let the TRON project director's statements influence their evaluation of the project anymore than they would trust Bush for an objective statement of the effectiveness of the US government! At least one Japanese contributor has suggested that TRON was mainly a device by Japanese micro-manufacturers to gain time until they had something to match NEC (which holds something like ninety percent of the Japanese PeeCee market) for schools and other government funded applications. With twenty plus years studying Japan, six of them in Japan, my inclination would be to believe this particular Japanese contributor. I've read a variety of accounts of TRON in the Japanese press (primarily the Nihon keizai shinbun), and from this I received only one consistent impression: even reasonably well-versed Japanese journalists cannot figure out TRON. Sometimes it appears like a Nintendo game machine with balls. Other times it appears like a UNIX killer (or knock off). Some accounts have styled it a second-generation MSX system. So far, my overall impression is that TRON is second only to the FGP (Fifth Generation Project) in terms of hype. If Japan had a William Proxmire, it would have received a Golden Fleece award. Nevertheless, I am open to counter evidence presented in either English or Japanese (any common kanji protocol or fax). If any Japanese reader feels he/she cannot properly describe the wonders of TRON in English, I am willing to translate any concrete statement provided it is not too long. (Kanji transmissions should be processed with uuencode.) Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary (bitnet) ehkinmonth@ucdavis.edu (uucp) ucbvax!ucdavis!ucdked!cck (telnet or 916-752-7920) cc-dnet.ucdavis.edu [128.120.2.251] request ucdked, login as guest, no password
limonce@pilot.njin.net (Tom Limoncelli) (07/07/89)
In article <226@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: > From article <32424@apple.Apple.COM>, by baum@Apple.COM (Allen J. Baum): > > How about because the TRON hardware architecture is a really ugly > > CISC architecture which looks worse to build in hardware than the > > only somewhat ugly CISCs we already have to deal with. > > > Sorry, but I don't remember such terminology in Computer Science - ugly, > nice, beautiful... Strange. I hear and use those terms all the time. I guess that's what I get for being a CS major at a liberal arts college. I recommend you read "A Mathematician's Appology" by G.H. Hardy for a "technical" definition of "ugly". -Tom -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University "DEC's All-In-1 isn't completely useless, but it's a nice attempt."
trebor@biar.UUCP (Robert J Woodhead) (07/07/89)
In article <Jul.7.01.19.39.1989.7792@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >I recommend you read "A Mathematician's Appology" by G.H. Hardy for a >"technical" definition of "ugly". Woodhead's Postulation on Programming Pulchritude ``Beautiful programs, like beautiful women, are often /* commented */ upon.'' -- (^;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-;^) Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP ``I can read your mind - right now, you're thinking I'm full of it...''
chuck@melmac.harris-atd.com (Chuck Musciano) (07/07/89)
In article <6340@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes: >TRON's technical merits >(or lack thereof) will simply be irrelevant. The first economically-viable >infrastructure will always swamp any and all competition. This is not always true. Witness Edison and his promotion of DC power, which was supplanted by Tesla's AC system, or CBS's attempt to standardize on spinning wheel color television, or Sony Betamax videotape systems, or even Ford's planetary-gear transmission used in cars from the 1920s. While all of these systems were in place first as a "standard" and showed great promise, they were all replaced by later, better technology. Being first is not always a guarantee of success. Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004} Oh yeah, laugh now! But when the millions start pouring in, I'll be the one at Burger King, sucking down Whoppers at my own private table! --Al Bundy
uri@arnor.UUCP (Uri Blumenthal) (07/07/89)
From article <Jul.7.01.19.39.1989.7792@pilot.njin.net>, by limonce@pilot.njin.net (Tom Limoncelli): >> Sorry, but I don't remember such terminology in Computer Science - ugly, >> nice, beautiful... > > Strange. ........... I guess that's > what I get for being a CS major at a liberal arts college. > > I recommend you read "A Mathematician's Appology" by G.H. Hardy for a > "technical" definition of "ugly". Thanks, Tom. I can't help but to recommend you to read some books on CS, in my turn. It may enrich your lexicon with some "real" technical terms - so we'll not need to seek "technical" definition for UGLY. So be professional, please (I mean -even more (:-) - in CS, not in liberal arts... Uri.
passaret@brahe.crd.ge.com ("Mr. Mike" Passaretti) (07/08/89)
| In article <2296@trantor.harris-atd.com> | chuck@melmac.harris-atd.com (Chuck Musciano) writes: | |In article <6340@pdn.paradyne.com> |> alan@oz.paradyne.com (Alan Lovejoy) writes: |> |>TRON's technical merits |>(or lack thereof) will simply be irrelevant. The first economically-viable |>infrastructure will always swamp any and all competition. | | [....], or Sony Betamax videotape systems, [....]. While all of | these systems were in place first as a "standard" and showed great promise, | they were all replaced by later, better technology. Being first is not | always a guarantee of success. Yeah, right. Tell that to all the TV studios and news teams who use Beta-Cam. Just because the average bozo off the street doesn't care if HIS video looks like it's been put through a meat grinder doesn't mean that it's "better technology". (I assume here, you're talking about the Vile Home System. If you're talking about some other 1/2" system, I'd be happy to discuss that too). [Enter blathering about video mode. If you don't care about that, skip to the bottom for a quick summation (cut to the chase)] Consumer electronics aren't the "real world", chum. If they were, nobody would buy Ikegami studio monitors at a couple grand apiece... After all, Sanyo moves a lot more of their 19" cable-ready jobs than Ikegami sells monitors, right? Come on, you might as well say that UNIX has been replaced by MS-DOS. (OK, so that's a little extreme, but you get the picture). To be fair, here, nobody has quad machines in their home, and damn few people have 3/4" decks, cause the market is cost AND performance driven. Those machines were first on the scene, but not too many people have ever seen one. I guess it all depends on how you define "swamp any and all competition." Better products for some uses came along, so people used them (Beta for instance). Most of the people I know in the field will agree, however, that NOTHING beats the video quality you can get out of a properly set up quad. The problem is it's too hard to find someone with the patience and skill to set one up. Enter 3/4" and 1/2" cassette formats. No muss, no fuss. Worse video, but more likely to stay consistent without major operator intervention. Cheaper too. One might note here, as well, that Harris was NOT the first company to produce commercial broadcast equipment, but they have been very prominent in that field of late. [End blathering about video mode.] Let's face it, ALL technology has a place, and if there is a niche somewhere that TRON fills, first in the field or not, it will survive. Now whether that niche exists or not, that's a different horse of another color (as my grandpappy used to say). - MM -- There is no god but |ARPA: passaretti@crd.ge.com Ollie, and Stanley |UUCP: {philabs,rochester,uunet}!steinmetz!crd!passaretti is his prophet. |WRPI: 30 years of Aggressive Radio(tm) 91.5 FM, Troy, NY --
ted@nmsu.edu (Ted Dunning) (07/08/89)
In article <252@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes:
Thanks, Tom. I can't help but to recommend you to read some books on CS, in
my turn. It may enrich your lexicon with some "real" technical terms - so
we'll not need to seek "technical" definition for UGLY. So be professional,
please (I mean -even more (:-) - in CS, not in liberal arts...
terms like ugly, good, elegant and so on do not indicate that the
speaker is fuzzy minded even when applied to computer science. rather
they indicate are reasonable appreciation of the role of heuristic
decisions in the design and evaluation process.
only toy problems (such as are given to people in text-books and in
school) are really amenable to solutions purely on technical grounds.
in the real world of design and engineering there are an enormous
number of decisions that must be made long before the ultimate effect
of those decisions can be known. in such situations, a good designer
has a philosophy of design to fall back on that allows them to make
decisions in what is essentially a vacuum of hard data. an honest
designer will use qualitative, `non-technical' terms like ugly or
elegant to describe decisions made on this basis. a dishonest or
naive designer will deny the applicability of such terms to their
field (not intended to be an ad hominem attack).
it is also important to realize that for design to be a fulfilling
life work for anybody but an automaton, you must allow some outlet for
artistic impulses. creating a design that not only is functional, but
is a work of art in some sense greatly feeling of creating something
worthwhile.
these `fuzzy' terms DO have an important place in all engineering and
scientific disciplines. they function as guide-posts in the murk.khb@gammara.Sun.COM (gammara) (07/08/89)
In article <2296@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: >Sony Betamax videotape systems, or even... >they were all replaced by later, better technology. Being first is not always >a guarantee of success. I went VHS early on ... but beta seemed then (and does now) to be the technically superior product ... VHS had better licensing polcies ... Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/08/89)
In article <114351@sun.Eng.Sun.COM> khb@sun.UUCP (gammara) writes: >In article <2296@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: >>Sony Betamax videotape systems, or even... >>they were all replaced by later, better technology. Being first is not always >>a guarantee of success. The original posting that sparked this diversion gave several other examples. One was Edison pushing DC over AC (the "obviously" superior approach). Perhaps some of the EEs can correct me, but I was under the impression that DC was making a comeback for power transmission due to semiconductor technology. Perhaps in retrospect Edison was less pigheaded than visionary? He was "wrong" given the short run technical progress curve but not for the long?
alan@oz.nm.paradyne.com (Alan Lovejoy) (07/08/89)
In article <2296@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: >In article <6340@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes: >>TRON's technical merits >>(or lack thereof) will simply be irrelevant. The first economically-viable >>infrastructure will always swamp any and all competition. > > This is not always true. Witness Edison and his promotion of DC power, >which was supplanted by Tesla's AC system, or CBS's attempt to standardize >on spinning wheel color television, or Sony Betamax videotape systems, or even >Ford's planetary-gear transmission used in cars from the 1920s. While all of >these systems were in place first as a "standard" and showed great promise, >they were all replaced by later, better technology. Being first is not always >a guarantee of success. You misunderstood. But that appears to be my fault for not saying what I meant more clearly. If what you think I said were true, then we'd still live in caves, walk to work and use stone tools. Obviously, a new technology which is sufficiently better than that currently in use will become very popular. What I meant to say is this: A technology which creates an economically-viable infrastructure will always win out over all competing technologies which DO NOT CONSTITUTE OR BENEFIT FROM such an infrastructure. Fords and Chevys have an unassailable advantage over a car which gets its energy from solar-energy absorbing asphalt on specially designed roads. Until such roads are built, very few people will buy a car which cannot be operated on existing roads. The Japanese are going to be marketing TRON PC's, TRON audio equipment, TRON video equipment, TRON ovens, refrigerators, dishwashers, hot-water heaters and central heating/air-conditioning systems, TRON security systems and TRON lighting fixtures. With all that in your house, will you really be interested in buying an Intel HDTV system that is NOT TRON compatible? Don't forget you'll need a second remote control! ____"Congress shall have the power to prohibit speech offensive to Congress"____ Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me. Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.
hascall@atanasoff.cs.iastate.edu (John Hascall) (07/09/89)
In article <2296@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: >In article <6340@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes: >>TRON's technical merits >>(or lack thereof) will simply be irrelevant. The first economically-viable >>infrastructure will always swamp any and all competition. > This is not always true. Witness Edison and his promotion of DC power,... >Ford's planetary-gear transmission used in cars from the 1920s. BTW, the planetary-gear transmission is *the* transmission in (some classes of) auto racing these days.
peter@ficc.uu.net (Peter da Silva) (07/09/89)
In article <6350@pdn.paradyne.com>, alan@oz.nm.paradyne.com (Alan Lovejoy) writes: > The Japanese are going to be marketing TRON PC's, TRON audio equipment, > TRON video equipment, TRON ovens, refrigerators, dishwashers, hot-water > heaters and central heating/air-conditioning systems, TRON security systems > and TRON lighting fixtures. With all that in your house, will you really > be interested in buying an Intel HDTV system that is NOT TRON compatible? You can be TRON compatible without using a funky operating system on a brain- dead CISC micro. Designing your operating system around a communications protocol hasn't been successful in the past, you know. As a simile, consider that UNIX was developed on a PDP-11. How many systems here are PDP-11s? How many aren't even running UNIX? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "WHAT HAPPENED TO ALL Personal: peter@sugar.hackercorp.com. `-_-' | THE WOMEN IN TEXAS?" Quote: Have you hugged your wolf today? 'U` | -- ACS1W@jane.uh.edu (meesh)
alan@oz.nm.paradyne.com (Alan Lovejoy) (07/09/89)
In article <4919@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >You can be TRON compatible without using a funky operating system on a brain- >dead CISC micro. Just like you can be IBM-PC compatible without using MS-DOS on a brain-dead Intel-based micro? True but irrelevant. As history has shown, businessmen do not think like techies. MS-DOS machines with Intel CPUs vastly outnumber UNIX workstations for business, not technical, reasons. Why should Westinghouse spend mucho money to develop their own proprietary TRON-like system for household appliances when they can leverage off of the investments the Japanese have made in STANDARD tools? ____"Congress shall have the power to prohibit speech offensive to Congress"____ Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me. Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.
limonce@pilot.njin.net (Tom Limoncelli) (07/09/89)
In article <252@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: > From article <Jul.7.01.19.39.1989.7792@pilot.njin.net>, by limonce@pilot.njin.net (Tom Limoncelli): > >> Sorry, but I don't remember such terminology in Computer Science - ugly, > >> nice, beautiful... > > > > Strange. ........... I guess that's > > what I get for being a CS major at a liberal arts college. > > > > I recommend you read "A Mathematician's Appology" by G.H. Hardy for a > > "technical" definition of "ugly". > > Thanks, Tom. I can't help but to recommend you to read some books on CS, in > my turn. It may enrich your lexicon with some "real" technical terms - so > we'll not need to seek "technical" definition for UGLY. So be professional, > please (I mean -even more (:-) - in CS, not in liberal arts... > > Uri. If you re-read what I posted, you'll see that I *am* a CS major, I'm *at* a liberal arts university. Though I am a student, I also run a team of programmers at our computer center. These are usually medium-large applications for use by non-computer people on our VAX. "Are you just a automaton or what?" is a question I ask many programmers. If you don't plan a good, sound, (may I use the word 'elegant'?) design from the start (in other words, if you don't THINK) it will catch up with you later. By not only designing products, but keeping a good design philosophy in all your programs, you prevent mistakes. For example, I'm very consistant with my string handling and I require all my code (and the code of people that I manage) to handle all the "what if's". For example, I always handle special cases like null-strings even if they shouldn't creep into that subroutine. Another example is that we include ELSE clauses on more IF-THEN statements than most people would. Many times the ELSE just outputs "Should Never Execute: ID=" and then a unique number. This helps out the bug-testers. Now, you may disagree with those design philosophies or agree; there are reasons for and against doing things that way; but it's a design philosophy that we keep, and we all rely on them. I would NEVER blindly require those kind of conditions at the next site I work; but they work well here. It's interesting to note that recently the powers-that-be requested a new function in something. One asked if it could be done by leaving something in the config file blank. I didn't think I was pressing my luck by attempting it in front of them because I trusted the code. The null string was generated properly and propagated through the entire program and it never, ever crashed. In no way had the program been designed to handle a null-string there but it worked. I saved about a week of re-writes because I was careful in my pre-planning. Literally an ounce of forethought saved me a week in re-writing. Maintain a good philosophy and the good philosophy will maintain you. Why don't *you* become more professional, Sir. It only hurts the industry when a programmer can't think for him/her self. I have seen too many people angry at the entire industry because one consultant provided a solution that was one kludge on top of another; all held together by spit and glue. ...and it fell apart at the wrong moment. I ask you, is that design philosophy or is that ethics? Maybe what CS majors need is a little more philosophy. -Tom -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University "DEC's All-In-1 isn't completely useless, but it's a nice attempt."
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/10/89)
>The Japanese are going to be marketing TRON PC's, TRON audio equipment, --------------------| Would not "some Japanese manufacturers will try to market" be more appropriate in this context? >TRON video equipment, TRON ovens, refrigerators, dishwashers, hot-water >heaters and central heating/air-conditioning systems, TRON security systems >and TRON lighting fixtures. With all that in your house, will you really --------------------------------| Unless things have changed since my last stint in Japan (1988), microprocessor controlled wc's (heads, johns, crappers, etc.) are fairly common. I trust these will integrate with TRON. Just imagine. TRON will monitor the oven, the rice cooker (more important than the former), the fridge, etc., integrate this with n-months stored data on the processing speed of my bowels and intestines, and have the wc all primed and ready for the next big event (daiben) when it comes.... (For a good introduction to modern Japan, read BRAVE NEW WORLD by Aldus Huxley!) >be interested in buying an Intel HDTV system that is NOT TRON compatible? >Don't forget you'll need a second remote control!
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (07/10/89)
From limonce@pilot.njin.net (Tom Limoncelli): > I require all my code [...] to handle all the "what if's". [...] > I saved about a week of re-writes because I was careful in my pre-planning. > [...] Maybe what CS majors need is a little more philosophy. Sorry, Tom, this isn't philosophy. It's software engineering. And yes, it is indeed unfortunate that many CS majors who graduated several years back were able to get their degrees without a software engineering requirement. Those persons can now upgrade their skills at the local University Bookstore. Bill Wolfe, wtwolfe@hubcap.clemson.edu
lexw@idca.tds.PHILIPS.nl (Lex Wassenberg) (07/10/89)
In article <26118@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: > >The original posting that sparked this diversion gave several other >examples. One was Edison pushing DC over AC (the "obviously" superior >approach). Perhaps some of the EEs can correct me, but I was under the >impression that DC was making a comeback for power transmission due to >semiconductor technology. Perhaps in retrospect Edison was less >pigheaded than visionary? He was "wrong" given the short run technical >progress curve but not for the long? I don't know whether DC is making a comeback in power transmission, but even if it is, Edison was wrong *at the time*. He hadn't ever heard about semiconductors, but still thought DC was superior over AC, even with the technology of that time. History has proven that he was definitely wrong on that point. ________________ / / ___ _____/ Lex Wassenberg, Philips TDS / / /__ \/ ___/ Apeldoorn, The Netherlands / / ___/ /__ lexw@idca.tds.philips.nl / / /____/\___/ / /____________/ It's said that only 10 people on the whole world understood /_______________/ Einstein. I'm so brilliant that nobody understands me at all. Disclaimer: Since nobody understands me, I speak only for myself.
diamond@diamond.csl.sony.junet (Norman Diamond) (07/10/89)
Sorry for dropping comp.realtime from the distribution. rn wisely knows to abort when I try to followup to a group that we don't get. In article <26079@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >Other times it appears like a UNIX killer (or knock off). Well, it is better thought out than Unix. There have been twenty years of newer inventions since the creation of Unix, and Tron takes about 33% of the possible advantage that it could have taken. >So far, my overall impression is that TRON is second only to the FGP >(Fifth Generation Project) in terms of hype. True. But there is some technical substance behind it. The technical advance is less than it should be but greater than zero. The garbage component is larger than it should be but less than 100%. >If Japan had a William >Proxmire, it would have received a Golden Fleece award. Not true! It does not receive political funding like 5th generation or like the projects that Proxmire gives awards to. Indirectly it does receive some tax funding just like the endeavors of U.S. universities are tax-supported. And private companies make private investments. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are claimed by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo, Stanford, or Anterior, then their administrators must have approved of these opinions.
peter@ficc.uu.net (Peter da Silva) (07/10/89)
In article <6353@pdn.paradyne.com>, alan@oz.nm.paradyne.com (Alan Lovejoy) writes: > In article <4919@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >You can be TRON compatible without using a funky operating system on a brain- > >dead CISC micro. > Just like you can be IBM-PC compatible without using MS-DOS on a brain-dead > Intel-based micro? But you can't. > True but irrelevant. No, it's completely relevant. You're confusing the CPU with peripherals. > As history has shown, businessmen > do not think like techies. MS-DOS machines with Intel CPUs vastly outnumber > UNIX workstations for business, not technical, reasons. Why should Westinghouse > spend mucho money to develop their own proprietary TRON-like system for > household appliances when they can leverage off of the investments the > Japanese have made in STANDARD tools? Why would hundreds of companies make plug-compatible peripherals for IBM computers... from PCs to mainframes... when you can buy them from IBM? Why would anyone build a modem that didn't depend on a standard 1200-baud chipset? Why would anyone bother putting their own master-mode controller in their IBM-PC cards when there's already a DMA controller on the mother- board? Why would anyone buy an HP laser printer when it doesn't contain Adobe software? Superior performance and/or lower price. If I can spend a million dollars developing a widget that duplicates the widget I can license from Joe, but his licensing fees would come to two million over the life of the product, why shouldn't I do it myself? If I can spend two million and get a superior product, why shouldn't I? And there's another fallacy in your statement. Why should Westinghouse wait for the Japanese to develop a set of standard tools for which there are no trained programmers, when US universities are turning out untold numbers of people already familiar with EXISTING standard tools? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "WHAT HAPPENED TO ALL Personal: peter@sugar.hackercorp.com. `-_-' | THE WOMEN IN TEXAS?" Quote: Have you hugged your wolf today? 'U` | -- ACS1W@jane.uh.edu (meesh)
sccowan@watmsg.waterloo.edu (S. Crispin Cowan) (07/10/89)
In article <2296@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: >In article <6340@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes: >>TRON's technical merits >>(or lack thereof) will simply be irrelevant. The first economically-viable >>infrastructure will always swamp any and all competition. > This is not always true. Witness Edison and his promotion of DC power, >which was supplanted by Tesla's AC system, or CBS's attempt to standardize >on spinning wheel color television, or Sony Betamax videotape systems, or even >Ford's planetary-gear transmission used in cars from the 1920s. While all of >these systems were in place first as a "standard" and showed great promise, >they were all replaced by later, better technology. Being first is not always >a guarantee of success. Better is not necessarily a guarantee of success, either. Betamax came first, and is definately _better_ (higher resolution), but VHS was cheaper, which lead to wider proliferation of machines, which lead to more software (movies), <goto wider proliferation>. Sony's marketing people failed to grasp this, as they headed upscale at just the wrong time. This same effect explains MESS-DOS. Markets that require support are feedback loops, and thus are meta-stable. Whenever any standard starts to get a lead, it will feed back on itself, and only very large effects can change the course of the market place after that. The important element of success is to convince a large chunk of the market that you're ahead, _before_ anyone really is. >Chuck Musciano ARPA : chuck@trantor.harris-atd.com >Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck >PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 >Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004} > >Oh yeah, laugh now! But when the millions start pouring in, I'll be the one >at Burger King, sucking down Whoppers at my own private table! --Al Bundy ---------------------------------------------------------------------- Login name: sccowan In real life: S. Crispin Cowan Office: DC3548 x3934 Home phone: 570-2517 Post Awful: 60 Overlea Drive, Kitchener, N2M 1T1 UUCP: watmath!watmsg!sccowan Domain: sccowan@watmsg.waterloo.edu "Everything to excess. Moderation is for monks." -Lazarus Long
uri@arnor.UUCP (Uri Blumenthal) (07/10/89)
From article <Jul.9.12.59.44.1989.22438@pilot.njin.net>, by limonce@pilot.njin.net (Tom Limoncelli): > > "Are you just a automaton or what?" is a question I ask many > programmers. If you don't plan a good, sound, (may I use the word > 'elegant'?) design from the start (in other words, if you don't THINK) > it will catch up with you later. > Well, since I'm not going to quarrel, I'll leave this alone. > Now, you may disagree with those design philosophies or agree; there > are reasons for and against doing things that way; but it's a design > philosophy that we keep, and we all rely on them. I would NEVER > blindly require those kind of conditions at the next site I work; but > they work well here. > > Why don't *you* become more professional, Sir. It only hurts the > industry when a programmer can't think for him/her self. I have seen > too many people angry at the entire industry because one consultant > provided a solution that was one kludge on top of another; all held > together by spit and glue. ...and it fell apart at the wrong moment. > I ask you, is that design philosophy or is that ethics? > > Maybe what CS majors need is a little more philosophy. > I've already answered such an "attack", though that one was a lot kinder, more "professional", I'd say. I'm repeating: actually there's nothing wrong when somebody uses such terms SOMETIMES. Well, everybody probably has met nice programs, and even more - ugly ones. But listen, to start discussion about new, unfamiliar to most of us (I daresay) product with a sentence "it's ugly" - it doesn't sound too reasonable for me. Again: DESCRIBE it at first, and we'll see then what it is - ugly or not. What did you mean by "can't think for him/her self" please? If you're trying to start flaming - it's not the best place, neither it's decent (or at least polite) way to do it. Such ill-mannered (sorry, can't stop myself) offenses aren't nice at all. Since you haven't seen my programs, you'd better wait with judging them, OK? I'm not discussing yours... Design philosophy or ethics? Both (but of course). More philosophy for CS? Well, in my University we had plenty (no less than your "liberal", I'd say). Regards, Uri.
jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) (07/11/89)
In article <26118@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >One was Edison pushing DC over AC (the "obviously" superior >approach). Perhaps some of the EEs can correct me, but I was under the >impression that DC was making a comeback for power transmission due to >semiconductor technology. DC is making a comeback in extremely long haul transmission lines, partially, I believe, due to advances in switching DC converters made in the last few years. Losses are lower on these DC lines than on AC lines of similar length. >Perhaps in retrospect Edison was less >pigheaded than visionary? He was "wrong" given the short run technical >progress curve but not for the long? From what I understand about Edison, he simply did not have the background to understand the far more complex math needed to use AC, especially three-phase, AC circuitry. Edison is more regarded an experimentalist than a visionary. With regard to the transmission mode, "pigheaded" is probably an accurate description. -- Michael Lodman Mike.Lodman@SanDiego.NCR.COM NCR Corporation - Distributed Systems Lab - San Diego 9900 Old Grove Rd. San Diego, CA. 92131 (619) 693-5353
baum@Apple.COM (Allen J. Baum) (07/11/89)
[] >In article <226@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: >From article <32424@apple.Apple.COM>, by baum@Apple.COM (Allen J. Baum): >> How about because the TRON hardware architecture is a really ugly >> CISC architecture which looks worse to build in hardware than the >> only somewhat ugly CISCs we already have to deal with. >> >Sorry, but I don't remember such terminology in Computer Science - ugly, >nice, beautiful... > >More specific, please? Efficiency,performance,instruction set (oh, it's CISC, >but you probably know how WIDE this term is now, don't you), features? Is it >something like iAPX-432 (I mean - ideas)? > >P.S. Don't waste time flaming me - I'd rather like a technical answer. Well, it appears that the request for no flaming didn't work. Oh, well, sorry. To answer your question, the TRON architecture has lotsa opcodes, and many more lotsa addressing modes. Instructions range from 16-160 bits (this is probably an exaggeration, but I can't find my documentation on it right now, and it is a nice round order of magnitude :-) ) I seem to recall that addressing modes are more like addressing expressions. As a hardware guy, I would maintain that this is not only hard to build, but very difficult to make go fast, unnecessary, and therefore, "ugly". A friend of mine who worked on a compiler for TRON thought it was an incredible mess to compile for. More hearsay. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
jdm@a.cs.wvu.wvnet.edu (James D Mooney) (07/11/89)
Thanks for the continuing comments on the TRON project. The following is an attempt to organize and summarize the main ideas that seem to have been expressed so far. A few commenters spoke in favor of TRON, and a few more emphasized the importance of paying attention. The majority of comments, though, were highly critical, or suggested reasons why others might object to TRON. The critical comments fall more or less into three groups: I. GENERAL CRITICISMS: 1. Not enough information is easily available. 2. It's Japanese, not American. This seems to have several subthemes: a) TRON doesn't want non-Japanese participation. b) The West (U.S.?) does not want to share its technology with potential competitors. c) Big projects in Japan have lost credibility (citing 5th Generation, etc.) d) TRON is for Japanese products; Western countries have their own standards. 3. It's "design by committee," therefore likely to fail. 4. It isn't practical, and can't be implemented efficiently. II. TRON AS A STANDARD: 1. It's only a set of standards. There are too many standards. Standards are uninteresting and not useful. 2. TRON ignores existing standards. 3. TRON includes little real innovation. 4. No one will be required to use TRON. III. ELEMENTS OF TRON: 1. The global, all-encompassing TRON network is a threat to privacy (Big Brother is watching). 2. The TRON CPU is uninteresting, inefficient, CISC, and hard to program (did I also hear the term "ugly"?). 3. The TRON operating systems are glorified UNIX (or MSX). 4. The TRON operating systems are not compatible with UNIX (or MS-DOS). I think this summarizes the main ideas expressed. I apologize if I have misrepresented anything or left anything out. I have my own responses to some of these points; they will be saved for a later posting. These criticisms are also discussed in my commentary which should appear in the September Microprocessors and Microsystems. Jim Mooney Dept. of Stat. & Computer Science (304) 293-3607 West Virginia University Morgantown, WV 26506 INTERNET: jdm@a.cs.wvu.wvnet.edu
news@ism780c.isc.com (News system) (07/12/89)
In article <33015@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >[] >>More specific, please? Efficiency,performance,instruction set (oh, it's CISC, >>but you probably know how WIDE this term is now, don't you), features? Is it >>something like iAPX-432 (I mean - ideas)? >> >>P.S. Don't waste time flaming me - I'd rather like a technical answer. > >Well, it appears that the request for no flaming didn't work. Oh, well, sorry. > >To answer your question, the TRON architecture has lotsa opcodes, and many more >lotsa addressing modes. Instructions range from 16-160 bits (this is probably >an exaggeration, but I can't find my documentation on it right now, and it is >a nice round order of magnitude :-) ) I seem to recall that addressing modes >are more like addressing expressions. >{decwrl,hplabs}!amdahl!apple!baum As an implementor of an assembler and a C compiler for the machine I can make some comments. The assembler recoginizes 442 opcode names. But the actual number of machine instructions is greater than this. For an opcode name like 'mov' the assembler selects from one of 7 different machine instructions depending on the operands. Allen Baum is correct about instruction complexity. But his 160 bit estimate was conservative. Here is an example of a single instruction. The number of bits in the instruction is 416. And there are instructions that are even longer than this one. mov @(@(@(@(a,r1),b,r2),c,r3),d,r4), @(@(@(@(a,r1),b,r2),c,r3),d,r4) D20B 4412 0003 0D40 4812 0004 93E0 4C12 0006 1A80 9012 0000 C350 8A0B 4412 0003 0D40 4812 0004 93E0 4C12 0006 1A80 9012 0000 C350 The block of hex digits is the object form of the assembly source line. This form of 'mov' does a memory to memory move. The address is computed as follows: 1. The displacement 'a' is added to the contents of r1. The contents of the 32 bit word at this memory location becomes the base address for the next step. 2. The displacement 'b' and the contents of r2 are added to the base to form a new memory address. The contents of this memory location is the new base. 3. step three is repeaed twice more using (c,r3) and (d,r4) 4. The result of all this is the address of the operand to be moved. Arithmetic instructions come in two flavors, signed and unsigned. For example: add -- signed add addu -- unsigned add The instruction: add @x.b, r9.w Will add the byte at memory location 'x' to register r9 treated as a word. The source operand is sign extended. Addu does zero extension. Also add and addu produce different condition codes with the same inputs. In general the source operand may be a byte, two bytes, four bytes, or eight bytes wide. And the destination may be any of those sizes. (some versions of the machine to not provide all sizes). There are instructions for accessing bit fields, for operating on doubly linked lists, and for operating on count strings and strings terminated by a program defined sentinal. Conditional branches are done by adding a signed displacement to the program counter. The displacement may be 8, 16, or 32 bits. For the case of 8 bits, the displacement appearing in the instruction is shifted left one before being added. 16 and 32 bit displacements are not shifted but they must be even numbers. One interesting point. Our compiler generated a sequence like: mov @(20,r1*4), r0 mov r0, @(x) The peep whole optimizer replaced the two instructions with the single instruction: mov @(20,r1*4), @(x) It turns out that the original pair executes just as fast as the single instruction. Furthermore, the single instruction takes just as much memory as the two that it replaced. Because a lot of the instruction complexity is hidden by the assembly language we did not notice this anomaly until after we wrote the peep whole optimizer. As to code density, out measurements show that programs are smaller than corresponding 386 programs (a similar compiler was used for both machines). I will make no comment about performence because the machine comes in many models. I have written assemblers for over a dozen machines, and this one is by far the most complex. However, as seen by the assembly langague programmer (or the compiler writer) it looks very orthoginal. Marv Rubinstein
garyb@iotek.UUCP (Gary Burrell) (07/12/89)
In article <29418@ism780c.isc.com> marv@ism780.UUCP (Marvin Rubenstein) writes: > >As an implementor of an assembler and a C compiler for the machine I can make >some comments. The assembler recoginizes 442 opcode names. But the actual >number of machine instructions is greater than this. For an opcode name like >'mov' the assembler selects from one of 7 different machine instructions >depending on the operands. Allen Baum is correct about instruction >complexity. But his 160 bit estimate was conservative. Here is an example >of a single instruction. The number of bits in the instruction is 416. And >there are instructions that are even longer than this one. > > mov @(@(@(@(a,r1),b,r2),c,r3),d,r4), @(@(@(@(a,r1),b,r2),c,r3),d,r4) > > D20B 4412 0003 0D40 > 4812 0004 93E0 4C12 > 0006 1A80 9012 0000 > C350 8A0B 4412 0003 > 0D40 4812 0004 93E0 > 4C12 0006 1A80 9012 > 0000 C350 > >The block of hex digits is the object form of the assembly source line. >This form of 'mov' does a memory to memory move. The address is computed >as follows: Can you say "GAG" Boys and Girls ! Sure you can it's easy!!! > > Marv Rubinstein Gary Burrell <<<<<<******>>>>>> Gary R. Burrell, Iotek Inc, |*| E-Mail: garyb@iotek.uucp |*| 1127 Barrington St., Suite 100, |*| Fax: (902)420-0674 |*| Halifax, N.S., B3H 2P8, Canada |*| Phone: (902)420-1890 |*| Damm it Jim I'm a Doctor not a Computer Scientist! *************************************
a36773@tansei.cc.u-tokyo.JUNET (Ken SAKAMURA) (07/13/89)
Dear Colleagues, I understand that Dr. Mooney's questinaire produced a flurry of postings on the TRON project. As the leader of the project, I am delighted to hear frank opinions on the project from many people. I have followed only the beginning part and then could keep up with the network due to my teaching load at the University of Tokyo. So what I have summarised may be a little out of date. Please excuse me on this. I noticed that the TRON project is not widely known at least in the USA. If you can spare some time, reading the following articles/books gets you enough knowledge to discuss the topics on the TRON project in a constructive mannner. Sakamura, Ken (ed). IEEE MICRO Special issue on TRON. Vol 7, No. 2, April 1987. Sakamura, Ken (ed.) TRON Project 1987: Open-Architecture Computer Systems (Proceedings of the Third TRON Project Symposium) Springer-Verlag, Tokyo, 1987 Sakamura, Ken (ed.) IEEE MICRO special issue on the 32-Bit Microprocessor in Japan. Vol. 8, No. 2, April 1988. Sakamura, Ken (ed.) TRON Project 1988: Open-Architecture Computer Systems (Proceedings of the Fifth TRON Project Symposium) Springer-Verlag, Tokyo, 1988 Sakamura, Ken, and Sprague, Richard. The TRON Project. BYTE, Vol 14, No. 4, April 1989, pp. 292-301. Sakamura, Ken (ed) IEEE MICRO Special Far East issue. Vol. 9, No. 3, June 1989. I understand that our efforts to publicize the result of the TRON project leave much to be desired. Also detailed specifications are made available only after they reach the final stage of design. During the design phase, the members of the TRON associations are the ones who discusses the pros and cons of the intermediate designs. Since there are more than 100 companies including companies from the U.S.A., our efforts to disseminate the information are focused to the members of the TRON Association. I understand that there are many opinions as to the details of the specifications. We already have a diversity of opinions from the TRON association memebers. Let me just point out that the one of the major targets of the TRON project is to standardize computer interfaces of the electronics appliances that have much influence on our every day life. I can't speak for U.S.A., but at least in Japan many home appliances have built-in microprocessors and the trend to incoporate computers will continue. The power of microprocessors make home appliances to perform many fancy things, but some of these become too difficult for ordinary men and women to use. The best way to solve this problem is to let the computers offer better human-machine interface. Of course, we don't want to use additional separate computers, but the built-in computers should support such interface. Such interface must handle somewhat complex operations other than simple turning on/off switches. Standardization of such interface is the only way to have a comprehensive home automation that allow us to use many computer-controlled objects in a harmonious way. Regarding the large number of wires in the TRON house reported in a segment of CNN program, I should mention that the TRON house reported is an experimental one and we intentionally incoporated many wires that should have been invisible. (We will use better technology to route sensor signals, and other control signals in real TRON houses in the future.) That is why there are so many visible wires today in the TRON house. It is certainly shocking, isn't it? By the way, the enhanced capability of the home appliances and houses are not meant to improve the conditions of people in general only. We have already paid close attention to the way these computer controlled objects may help the handicapped and the old. Such considerations are very important when the birth rate in industrialized countries have begun dropping. My guess is that the first encounter of many people in U.S.A with the products based on the TRON specification will be in the home of computer-controlled home appliances. Regards, Ken Sakamura.
wsmith@mdbs.UUCP (Bill Smith) (07/14/89)
] >Instructions range from 16-160 bits (this is probably
] >an exaggeration, but I can't find my documentation on it right now, and it is
] >a nice round order of magnitude :-) ) I seem to recall that addressing modes
] >are more like addressing expressions.
] >{decwrl,hplabs}!amdahl!apple!baum
]
] But his 160 bit estimate was conservative. Here is an example
] of a single instruction. The number of bits in the instruction is 416. And
] there are instructions that are even longer than this one.
]
] mov @(@(@(@(a,r1),b,r2),c,r3),d,r4), @(@(@(@(a,r1),b,r2),c,r3),d,r4)
]
What will happen when such an instructions crosses a page boundary and
a page fault occurs? Is there some trickery that must be written into
the operating system to avoid thrashing when the instruction is restarted.
I've heard that the VAX can have instructions that can be very long. Do
VAXEN need to be careful in this situation as well?
Bill Smith
uunet!pur-ee!mdbs!wsmithhascall@atanasoff.cs.iastate.edu (John Hascall) (07/15/89)
In article <1449@mdbs.UUCP> wsmith@mdbs.UUCP (Bill Smith) writes: >] >Instructions range from 16-160 bits (this is probably >] But his 160 bit estimate was conservative. Here is an example >] of a single instruction. The number of bits in the instruction is 416. And >] there are instructions that are even longer than this one. >] mov @(@(@(@(a,r1),b,r2),c,r3),d,r4), @(@(@(@(a,r1),b,r2),c,r3),d,r4) >What will happen when such an instructions crosses a page boundary and >a page fault occurs? Is there some trickery that must be written into >the operating system to avoid thrashing when the instruction is restarted. >I've heard that the VAX can have instructions that can be very long. Do >VAXEN need to be careful in this situation as well? The longest instruction on a VAX is 37 bytes (296 bits). VAX instructions are 1 byte of opcode (there are a few 2 byte opcodes--mostly quadruple precision) followed by the operand specifier(s). No instruction has more than 6 operands and the longest operand specifier is 6 bytes: @789ABCDE(Rn)[Ri] or 789ABCDE(Rn)[Ri] It seems to me that the instruction (including operand specifiers) can be in at most 2 pages, and a "@displacement(Rn)[Rindex]" operand can reference 4 pages (2 references [address of operand & operand] * 2 pages [both happen to straddle a page boundary]) giving 2 + (6 * 4) = 26 pages which must be able to be in memory. I don't know of an special mechanism that would prevent one of the required pages from being selected as the victim to page-in one of the other required pages. I suspect they rely on this being a low probability event (in the worst case an extra page-in [or so]). I also seem to recall some minimum number of in-memory pages for a process which I suspect must be somewhat above 26. John Hascall
mohta@necom830.cc.titech.junet (Masataka Ohta) (07/22/89)
In article <382@h.cs.wvu.wvnet.edu> jdm@a.cs.wvu.wvnet.edu (James D Mooney) writes: >The goal of TRON is to develop a wide-ranging collection of standards >for use in a very comprehensive distributed network TRON was supported by many vendors because it prevent NEC from monopolizing the government's computer market for education. As NEC's PC9801 (msdos 8086 machine) was the only usable machine when department of education was choosing the machine for education, other vendors cooperated and promoted TRON as their standard. TRON have surely succeeded to delay the final decision and many vendors are now ready with their own MSDOS machines. Partly because of the above fact and partly because TRON can not achieve its promised (but impossible) goal yet, TRON is no longer a requirement for educational computers. MSDOS is OK. Thus, TRON has finished its political role. >Whether the TRON standards are good or bad, the project's scale, and >results to date, make it certain that it will have some impact. Bad standards will have bad impacts. >*WHY DOESN'T ANYONE SEEM TO CARE?* MOST JAPANESE RESEARCHERS DO NOT CARE EITHER. WE USE UNIX. >6. Other? 1) TRON is ugly and bad standard in all respect. 2) It is my impression that TRON itself dose not want open discussion with knowledgeable people. It prefers an average people (like average CNN watchers) who can be easily deceived. Masataka Ohta mohta%cc.titech.junet@relay.cs.net PS I don't like MSDOS, but it is far better than TRON.
markz@ssc.UUCP (Mark Zenier) (07/23/89)
> >From article <382@h.cs.wvu.wvnet.edu>, by jdm@a.cs.wvu.wvnet.edu (James D Mooney): > > *WHY DOESN'T ANYONE SEEM TO CARE?* > The research community doesn't care because it is someone elses project. Industry doesn't care because it isn't a product yet. The whole mess looks like another non-tariff barrier to me. F.Y.I there is a book on TRON, from either academic press or Springer Verlag. Mark Zenier uunet!nwnexus!pilchuck!ssc!markz markz@ssc.uucp uunet!amc!