mash@mips.COM (John Mashey) (10/30/88)
A bunch of people have emailed me random questions about the "BRAWL" I mentioned before, as well as related topics. Rather than emailing everywhere, I'll post some answers, trying pretty hard to be fairly objective: >Also, betting on a new architecture at the beginning of a cycle [i.e., >in the Z8000/68K/X86/X32 etc wars in the early 80s, and the current >BRAWL (Big RISC Architecture War & Lunacy) is very exciting,.... >Consider, choosing an architecture >is like an odd form of Russian Roulette: you pick a chip and pull the >trigger, then wait a year or two to see if you've blown your brains out. >Fortunately, the BRAWL will be over before the end of the year, >which will make life saner. Q: WHAT WAR ARE YOU TALKING ABOUT? A: There are at least 2: War1: Systems design-ins (esp. UNIX) War2: Embedded controllers (anything from airplanes to laser printers) The war is similar to the early-80s design-in battles: get there first into new application areas and get enough successful design-ins for your architecture that make it one of the "standards" (whatever THAT means). Q: WHO ARE THE SIDES? A: This is very complicated, especially as the turf is split up in ways where -some are publicly committed -some are committed, but not publicly -some are not yet committed, but they're now down to choice amongst at most 2 architectures. -some sell computers and/or chips to companies who are otherwise even publicly committed to somebody else (!) -some people's business causes them to play with multiple sides (This is like Diplomacy or RISK, if you know those games). War1: (major sides) MIPS & friends (R3000) Semi partners: Performance Semiconductor, Integrated Device Technologies, LSI Logic; +2 more (large ones) to be named soon. Sample of announced, committed design-ins: DEC, Tandem, SGI Motorola & friends (88000) Sample of announced, committed design-ins: Data General, Stratus, Tektronix Sun & friends (SPARC) Semi partners: Fujitsu, LSI Logic, Cypress, Texas Instruments; BIT Sample of announced, committed design-ins: AT&T, Xerox, Arix There is a bewildering variety of licensing arrangements (hardware, software, "architecture", designs, etc) that surround all of this. An "architecture" license lets somebody build hardware that follows your architecture, usually where they might want to do something different (beyond semiconductor partners). Public examples include: SPARC: Prisma (GaAs), Solbourne; MIPS: DEC; Motorola: DG. Finally, the last wild-card in this war is the Intel N-10, which is lurking around behind the scenes, but not announced. There probably can't be more than about 2 real winners in this one; all the sides have differing combinations of strengths and weaknesses; we all beat each other up as often as possible (like, next Wed's Santa Clara IEEE meeting, for example, with MIPS, Moto, and Sun.) War2: (I don't understand this as well, as it's handled more by our semiconductor partners; also MIPS, right now, mostly plays in the high end of this.) Still, here's a cut: AMD (29000) (aimed at embedded; medium-high to high end) Intel 80960 (embedded; medium to medium-high, as far as I can tell; maybe Intell-ites will say something). MIPS (R3000) (in high end; in defense applications; where software is deciding factor; where general-purpose FP is important) (CISC chips of various ilks) [If somebody who knows can describe this better, please do.] This war is probably more prone to having multiple survivors. Q: WHY DO YOU LIST THEM THE WAY YOU DO? A: (MIPScentric): In War1, we used to fight with SPARC a whole lot for the systems design-ins; now we bang heads more with the 88K; we've only once seen the 29K in that arena. In War2, we most often run into the 29K, and others occasionally. Presumably, as you go down the performance range, AMD runs into other people. Q: WHY DO YOU CLAIM THE WAR WILL BE OVER BY THE END OF THE YEAR? A: This is an overstatement, in one sense, and accurate in another. Also, the 2 wars are somewhat separate, although they interact (if you can get volume in one of the Wars and reduce your costs, you might get an edge in the other war, or with customers who'd like the same chips&software for both systems & embedded applications.) War1: The first battle (get systems vendors to pick sides) will be over: ALMOST ANYBODY WHO DOESN'T ALREADY HAVE A RISC, AND WANTS ONE, WILL LIKELY PICK SIDES VERY SOON. This doesn't necessarily mean that they'll announce their choice; that means that typically the only other people who know will be the architecture vendor who won a given customer, and the one who came in second. (The winner must keep quiet, even though they'd rather not; the one in second place has little motivation to blab! :-) Then there will be an implementation frenzy, and the second battle will really get rolling, i.e., it's possible to win some parts of the first battle, and still lose the war, if you make promises to get the design-in, but things don't come together. [My boss calls this the distinction between the "air-war" and the "ground-war". The "air-war" is fought in the press, including rather long-term pre- announcements; the "ground-war" is fought in getting real products built and shipped.] War2: This is a little different, in that software is a major part of War1, and acts differently in War2. That is, a systems vendor, having chosen a RISC, will tend to stick with it, just as they did with CISCs, given the software investment, and even visibility of the architecture to users. Non-reprogrammable devices (laser printers, etc) need software also, and buyers certainly have some loyalty, but decisions can be and are made on a more project-by-project basis. Thus, this war won't be settled for a while. Q: WHO'S LEFT? A: Well, some important computer vendors are not publicly committed to a RISC: - for some, RISC isn't particularly relevant to their business. - some of them are making up their minds (and usually pretty soon) - some of them are committed, but not publicly Following is a quick sample (U.S. only, because I'm looking at nice magazine-provided list, grossly ordered by computer revenue: I had to guess a couple places from electronics-revenue numbers). *'d ones are the obvious up-for-grabs (at least publicly; I know better in a couple cases), and mentioning only ones where it seems RISC-micro choice is a relevant issue. IBM: ROMP (PC/RT) & followon DEC: MIPS *Unisys: - (contrary to press early this year; read Datamation September 1, 1988, page 53 if you don't believe me) HP: PA (Precision Architecture) *Honeywell: - *NCR: - *Apple: - *Wang: - Xerox: SPARC AT&T: SPARC (contrary to recent silly rumors, I think) CDC: - (MIPS, but only sort of, via Silicon Graphics) Data General: 88K *Prime: - (complex, because announced RISC_based hardware platforms are OEMed workstations and include many vendors; there are various side deals, incl. software, and MIPS is probably more in there than others, but would be hard to call from public data.) Tandem: MIPS Sun: SPARC InterGraph: Clipper Apollo: PRISM (DN10000) Tektronix: 88K (stops around $600M computer revenue in calendar 87) As you can see, some of the ones left are pretty interesting; I don't think I'm giving away anything to say that many of the *'d ones are basically 88K vs MIPS fights at this point. Q: WILL RISC CHIPS ELIMINATE CISC CHIPS? A: No, X86s, 68Ks, etc, will be with us forever. As discussed earlier in this newsgroup, you can usually keep tuning a CISC architecture to go faster: it just costs you more $ and time to do it. Hence, RISCs should maintain a performance advantage, even in the next round where everybody stuffs more things on single chips. The other place where the performance advantage is maintained is that some of the CISCs just don't have enough registers: good optimizers are still worth having, but they don't turbo-charge performance as much as they do for RISCs. Q: WHO WILL WIN? A: Well, that's the $64K question, isn't it? Stay tuned. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
dre%ember@Sun.COM (David Emberson) (11/01/88)
Gosh, there sure seems to be a lot of Sun and SPARC bashing going on in this group lately! First I read how we don't care about performance, then I read that Mips has gone and talked everyone out of using SPARC and that we aren't a serious competitor to them anymore. Pretty soon I suppose we'll just have to turn off the lights and go look for other--whoa! What's this? A 2:1 stock split? Big OEM orders from Fujitsu and Seiko? Vendors rallying around ATT's System V.4? #1 in the workstation business? #1 in RISC units shipped? Are we talking about the same company? :-) Dave Emberson (dre@sun.com)
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (11/01/88)
In article <75478@sun.uucp> dre%ember@Sun.COM (David Emberson) writes: > >Gosh, there sure seems to be a lot of Sun and SPARC bashing going on in this >group lately! First I read how we don't care about performance, then I read >that Mips has gone and talked everyone out of using SPARC and that we aren't >a serious competitor to them anymore. Pretty soon I suppose we'll just have >to turn off the lights and go look for other--whoa! What's this? A 2:1 >stock split? Big OEM orders from Fujitsu and Seiko? Vendors rallying around >ATT's System V.4? #1 in the workstation business? #1 in RISC units shipped? >Are we talking about the same company? :-) Don't forget the ex-cray folks we licensed sparc to. They claim 4nsec sparc by late '89 ! Before we turn out the lights, we probably should release a few more products. Then maybe we won't get bashed for low performance. Maybe we're just not cute anymore. Everyone loves kittens, but when pussy grows up to be a tough tomcat..... :> > > Dave Emberson (dre@sun.com) Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
pavlov@hscfvax.harvard.edu (G.Pavlov) (11/01/88)
In article <75575@sun.uucp>, khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) writes: > > Before we turn out the lights, we probably should release a few more > products. Then maybe we won't get bashed for low performance. > When you do (release a few more products), try tempering your enthusiasm for the Dhrystone a bit (say 30% or so). The bashing might go away then... greg pavlov, fstrf, amherst, ny
daveh@cbmvax.UUCP (Dave Haynie) (11/02/88)
in article <75478@sun.uucp>, dre%ember@Sun.COM (David Emberson) says: > Summary: Nothing succeeds like success... > #1 in RISC units shipped? Intergraph is also claiming to have shipped the largest number of RISC based machines, based on some reasonable number of Clipper based ~5MIP workstations shipped. Anyone know the real numbers on any of these? > Dave Emberson (dre@sun.com) -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
bcase@cup.portal.com (Brian bcase Case) (11/02/88)
Comment about SUN being ...
>#1 in RISC units shipped?
Intergraph claims to have shipped the largest number of RISC (stretching
it a bit, but...) microprocessors, with something like "over 50000
served." Has SUN surpassed this number?
Also, in answer to the previous question about the Z80000; yes, it is
real, but only the military is silly enough to buy it.aglew@urbsdc.Urbana.Gould.COM (11/02/88)
>Gosh, there sure seems to be a lot of Sun and SPARC bashing going on in this >group lately! First I read how we don't care about performance, then I read >that Mips has gone and talked everyone out of using SPARC and that we aren't >a serious competitor to them anymore. Pretty soon I suppose we'll just have >to turn off the lights and go look for other--whoa! What's this? A 2:1 >stock split? Big OEM orders from Fujitsu and Seiko? Vendors rallying around >ATT's System V.4? #1 in the workstation business? #1 in RISC units shipped? >Are we talking about the same company? :-) > > Dave Emberson (dre@sun.com) Hey, Dave, don't get me wrong. When I made my smiley about SUN making liars out of the folks who think that CPUs are no longer a bottleneck, I meant it well. SUN still has the attitude that software should do whatever it has to do to be functional, and hardware should provide the speed. That is a characteristic of a strong, brash, young company. Companies that trade off software functionality for system performance are typically older, more staid; the best "performance engineers", tuners and tweakers, come from such companies, but the best software does not. Are there companies that go for high functionality software, rely on hardware for high performance, as well as doing good software performance engineering? I like to think that I work for such a company, and I'm sure you like to think the same thing of your employer, too... Andy "Krazy" Glew. at: Motorola Microcomputer Division, Champaign-Urbana Development Center (formerly Gould CSD Urbana Software Development Center). mail: 1101 E. University, Urbana, Illinois 61801, USA. email: (Gould addresses will persist for a while) aglew@gould.com - preferred, if you have MX records aglew@fang.gould.com - if you don't ...!uunet!uiucuxc!ccvaxa!aglew - paths may still be the only way My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products. PS. I promise to shorten this .signature soon.
walter@garth.UUCP (Walter Bays) (11/05/88)
In article <10770@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes: >Intergraph claims to have shipped the largest number of RISC (stretching >it a bit, but...) microprocessors, with something like "over 50000 >served." Has SUN surpassed this number? I think it's 18,000 through the third quarter, which makes us the leader in merchant market RISC microprocessors. (Clipper C100's, and now C300's) As the "Microprocessor Report" points out, this is largely because we've been making them so long. I believe that rumors of SPARC's death have been greatly exaggerated, though one could wish... :-) The RISC wars are over?! It seems more like they're just beginning in earnest now that some of the more recent combattants are just taking the field. Perspective: How many 386's and 68020's have shipped? At least 18,001? -- ------------------------------------------------------------------------------ My opinions are my own. Objects in mirror are closer than they appear. UUCP: {pyramid,sri-unix,ingr}!garth!walter (415) 852-2384 USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303 ------------------------------------------------------------------------------
mash@mips.COM (John Mashey) (11/06/88)
In article <1742@garth.UUCP> walter@garth.UUCP (Walter Bays) writes: >I believe that rumors of SPARC's death have been greatly exaggerated, >though one could wish... :-) The RISC wars are over?! It seems more >like they're just beginning in earnest now that some of the more recent >combattants are just taking the field. Since posting <7361@winchester>, I've had a bunch of e-mail exchanges with people who read it as "demise of SPARC" or equivalent thereof. Let me clarify a few things where I said what I meant, but wasn't careful to explain all of things I didn't mean! 1) The posting was NOT intended to imply the demise of SPARC. Why would it? I don't believe that. It is CLEAR that SPARC has enough presence to survive. I do believe that it will be difficult for SPARC to win enough of the yet-to-be-committed large companies to become "the industry-standard" (as I noted, whatever THAT means). Note that "not being the industry standard" is NOT EQUAL to demise. It is also clear that MIPS Rxxxx also has enough presence to survive. 2) What is still unclear is whether or not Motorola can do the things needed to be a clear survivor with the 88K: a) Sign up more industry leaders b) Get customers thru the design cycle, and out the door with systems in volume, including 3rd-party software. soon enough to catch up with MIPS & SPARC. If Moto can accomplish these things, there will be 3 winners; if not, then 2. When I say it is unclear, I mean that it is NOT clear to me. (I also meant that the $64K question was not yet answered.) 3) People asked about the ordering of chips in each of the two wars, and why it was that way. It was alphabetical by war; I should have said so, as nothing else was implied. 4) Once again, the reason I claimed that the war would be over (or at least the first major battle to secure lots of important design-ins) is because I've been in too many meetings with people who claim they're going to decide before the end of the year. (It's not like major players haven't been evaluating the situation for some time; after all, many of them were getting briefings YEARS ago on products publicly announced this year. Thus, the "recent combatants" actually took the field a while back, even if they didn't say so publicly.) It is quite possible that some of them will delay their choices, and it is very likely that few of them will make their choices public when they make their choices. Nevertheless, a lot of them will choose pretty soon, and my claim is that their choices will determine what's really going to happen (at least in the systems war), even if it's not publicly obvious at that time, and even though much work will remain to be done. Argh! now, back to technical things.... -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
mslater@cup.portal.com (Michael Z Slater) (11/07/88)
> 18,000 Clipper units shipped to date, making it the largest-volume > merchant RISC processor To put this in perspective, Dataquest estimates 1987 68020 shipments at 746,000 and 1987 386 shipments at 710,000. Shipments for 68020/030 and 386 should be 1.5 to 2 million each in 1988. At our Microprocessors '89 symposium last week, Nick Tredennick quoted an article (sorry, I don't remember what article) as saying that Intel will ship more 386's between coffee break and lunch than all the SPARC guys combined will ship all year. In all fairness, SPARC is earlier on the curve than the 020 and 386, but these numbers do point out that volumes of CISC processors still dwarf those of RISC processors. Just as volumes of PCs dwarf volumes of UNIX workstations, and low-cost embedded control applications dwarf high-end (32-bit) embedded control applications. For RISC processors to reach anywhere near the volumes being projected, UNIX workstations are going to have to start invading the PC-DOS territory. And I don't see them doing that anytime soon. Michael Slater, Microprocessor Report, mslater@cup.portal.com 415/494-2677 550 California Ave, Suite 320, Palo Alto, CA 94306
mash@mips.COM (John Mashey) (11/08/88)
In article <11016@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: > >To put this in perspective, Dataquest estimates 1987 68020 shipments at >746,000 and 1987 386 shipments at 710,000. Shipments for 68020/030 and >386 should be 1.5 to 2 million each in 1988..... Yes. NO reasonable person expects the existing successful micros to suddenly go away. I'll repeat the last slide from a recent talk at UNIX Expo: PREDICTIONS 1. Will CISC architectures disappear? 2. Will CISC architectures be made faster? 3. Will they catch RISC architectures? 4. Will there be any successful new CISC architectures? ---------- my answers: 1. Don't be silly. 2. Yes. More silicon, fancy logic, and caches help anything. 3. No. Complexity/space, time, and sometimes too few registers. 4. No.* * (unless IBM feels like it) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
hankd@pur-ee.UUCP (Hank Dietz) (11/09/88)
In article <7809@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: ... > 4. Will there be any successful new CISC architectures? ... > 4. No.* I don't agree. There are two kinds of new CISC architectures which we can reasonably expect to continue to be successful in the future: 1. New CISC designs which embed execution mode(s) for compatibility with existing machine(s). For example, the Vax had a pdp11 mode and the 386 really doesn't look much like an 8086 except in that it can pretend to be one. Note that compatibility in this form is very much like having two processors in one, which is easy in microcode but.... (I'd rather see people performing static code analysis and transformation to make old code run on new hardware, but there will *always* be somebody who doesn't believe in that.) 2. Special-purpose processors. For example, it might be kinda neat to have IMSL microcoded so that each subroutine is an instruction... I'm not saying that an appropriate RISC machine couldn't run IMSL just as well, but rather that the cost & packaging of the special-purpose CISC processor can reach a rather large market. On this second note, I wonder how long it will be before everyone realizes that a CISC = RISC + ROM program? __ /| _ | | __ / | Compiler-oriented / |--| | | | | Architecture / | | |__| |_/ Researcher from \__ | | | \ | Purdue \ | \ \ \ \ hankd@ee.ecn.purdue.edu
mash@mips.COM (John Mashey) (11/10/88)
In article <9725@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes: >In article <7809@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: >> 4. Will there be any successful new CISC architectures? >> 4. No.* > >I don't agree. There are two kinds of new CISC architectures which we can >reasonably expect to continue to be successful in the future: >1. New CISC designs which embed execution mode(s) for compatibility > with existing machine(s). For example, the Vax had a pdp11 mode and > the 386 really doesn't look much like an 8086 except in that it can > pretend to be one. Note that compatibility in this form is very > much like having two processors in one, which is easy in microcode > but.... (I'd rather see people performing static code analysis and > transformation to make old code run on new hardware, but there will > *always* be somebody who doesn't believe in that.) Sorry, I should perhaps have added the words I said when I used the overheads. I specifically said I didn't mean 80486s, 68040s, etc, and I specifically said "architecture", not "design". I believe there will be 486s, 586s, 040s, 050s, etc, etc, probably "forever". If a 486 is considered a "new" architecture, as opposed to an evolution of an old one, then there is zero differentiation between "old" and "new"; it's like calling everything a RISC: the term loses any trace of meaning. >2. Special-purpose processors. For example, it might be kinda neat to > have IMSL microcoded so that each subroutine is an instruction... > I'm not saying that an appropriate RISC machine couldn't run IMSL > just as well, but rather that the cost & packaging of the > special-purpose CISC processor can reach a rather large market. It's certainly possible. Will they be successful? (Time will tell.) >On this second note, I wonder how long it will be before everyone realizes >that a CISC = RISC + ROM program? Not all of us agree with that statement..... :-) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
bpendlet@esunix.UUCP (Bob Pendleton) (11/11/88)
From article <7926@winchester.mips.COM>, by mash@mips.COM (John Mashey): > In article <9725@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes: > >>On this second note, I wonder how long it will be before everyone realizes >>that a CISC = RISC + ROM program? > > Not all of us agree with that statement..... :-) I've just finished reading "mips R2000 RISC Architecture" by Gerry Kane. The instruction set looks very much like vertical microcode. You could even imagine building a machine that packed 2 to 4 R2000 instructions into a 64 to 128 bit instruction word, calling it horizontal microcode, and executing each instruction in a subcycle of the main processor. But, hey, doesn't the instruction cache let you fetch multiple words from main memory? And isn't being able to execute 1 instruction/cycle more flexible than always having 4 instructions to execute? What I'm trying to say is that even though RISC machines look a lot like microcode engines your average microcode engine is nowhere near as flexible as a RISC, RISC+ROM != Microcode engine+ROM. So for a general purpose processor I'd have to say that CISC < RISC+ROM. For special purpose processors microcode running on problem specific microengines still wins. Bob P. -- Bob Pendleton, speaking only for myself. UUCP Address: decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet Reality is what you make of it.
hankd@pur-ee.UUCP (Hank Dietz) (11/14/88)
In article <1077@esunix.UUCP>, bpendlet@esunix.UUCP (Bob Pendleton) writes: ... > What I'm trying to say is that even though RISC machines look a lot > like microcode engines your average microcode engine is nowhere near ^^^^^^^ > as flexible as a RISC, RISC+ROM != Microcode engine+ROM. So for a > general purpose processor I'd have to say that CISC < RISC+ROM. For > special purpose processors microcode running on problem specific > microengines still wins. Fair enough, but who said anything about "average" things? My point was simply that creating a RISC design geared specifically to the task of interpreting an instruction set leads rather naturally to the design of a microcode engine. I was not claiming that you take a SPARC (or any other existing RISC design out there) and add ROM and you have exactly got some particular CISC. If you didn't like my "CISC = RISC + ROM" claim, here's another nasty: it is also true that "CISC = VLIW + ROM." Of course, the same disclaimers apply.... -hankd
colwell@mfci.UUCP (Robert Colwell) (11/15/88)
In article <9774@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes: >If you didn't like my "CISC = RISC + ROM" claim, here's >another nasty: it is also true that "CISC = VLIW + ROM." Of course, the >same disclaimers apply.... No CISC that I've ever seen. CISCs tend to be very irregular at the level where the microword is wide enough for this analogy to even be worth considering. You may have a ~100 bit microword, long enough to control a lot of hardware, but then the hardware is usually just bus tri-state enables, ALU function selects, register number, etc. If your analogy holds, you should be able to supply me with some CISC machine that I can remove the ROM from and see a VLIW in what remains. What CISC were you thinking of? Bob Colwell mfci!colwell@uunet.uucp Multiflow Computer 175 N. Main St. Branford, CT 06405 203-488-6090
fransvo@htsa (Frans van Otten) (11/17/88)
Silly question, I think, but what is VLIW ?
--
Frans van Otten
Algemene Hogeschool Amsterdam
Technische en Maritieme Faculteit
fransvo@htsa.uucp