From news Sun Aug 3 01:52:42 91 From: melling@cs.psu.edu (Michael D Mellinger) Subject: Re: New NeXT's in November? <3120@pdxgate.UUCP> In article <3120@pdxgate.UUCP> a0cb@.cc.pdx.edu (Chris Bertholf) writes: Binary compatability with what. Almost every major manufacturer that has looked at the 88K has found it to be technologically deficient in several areas. Sure it's nice that Motorolla came out with a BCS, but since basically noone will be using it besides Motorolla and the few companies that sign on, it will be a very small customer base that can be targeted based on an 88K BCS. Incidentally, Intel, IBM, MIPS, SPARC, and most other RISCs also have binary compatability standards. Binary compatible with most every other NeXT!! That way people who set up networks of NeXTs don't have to play around with two different binaries. I'd agree that RISC is ONE OF the most promising technologies in the near future, but not Motorollas version of it. Their entire manufacturing facilities will have to be re-worked to support the manufacturing of the IBM POWER RISC chip, since it uses technology beyond that which Motorolla currently has. How do you expect them to compete with a RISC chipset that is inferior to the ones they will be producing for their competitors. Sabatoge IBM RISC? :-). Hire some smart people who know something about RISC? With Intel and IBM working on versions of their RISC processors that combine the best of RISC and VLIW technologies, and by the time that Motorolla gets up to speed, these other chips will be defacto standards with large installed customer bases and backwrad compatability with the first versions of their RISC-only processors. The 88K really is no more promising than the i860 is as a general purpose RISC chip. Admittedly, the i860 has more caveats than the Motorolla architecture, but the Motorolla is not doing much better. The current 88K is as fast or faster than the 68040, at least from the SPECmarks that I've seen. A lot will depend on NeXT. Will they ever sell 1 million machines a year? You might want to consider that Motorola might still have a little company pride, and they might not like the idea of making IBM's chips. Look at MIPS. They beat everyone in the microprocessor game. They're not exactly a large company. Betting your future on the 88K is almost as smart as betting it on the INMOS transputer. Neither one will probably get off the ground except in niche markets. This is 1991, the latter half of the 20th century. Switching microprocessors is only an inconvenience. It's not going to break every piece of software written for the NeXT(at least not significantly). By the fourth quarter of this year, IBM will have reduced the POWER architecture to a single chip implementation. Then they will start producing chips with more than a 25 MHz clock speed, and watch those SPECmarks jump. Motorolla, on the other hand, will still be working the bugs out of the 2 chip implementation of the 88K... Not a promising chip to bet your future on... You might be right. What's up with the 88110? Is it 60 mips or 100mips? NeXT might be better of going with the MIPS R3000, R4000(R6000...) chips. ACE(Microsoft/DEC/Compaq/MIPS) adopting these chips means that they will be *cheap*, and they're second sourced, unlike Motorola's chips. -Mike From news Sun Aug 5 17:46:06 91 From: a0cb@.cc.pdx.edu (Chris Bertholf) Subject: Re: New NeXT's in November? In article In article <3160@pdxgate.UUCP> a0cb@.cc.pdx.edu (Chris Bertholf) writes: Try to tell VARs and secondary software developers this. Especially if they have tuned their application(s) to the current hardware. Sure, it is 1991, but it is not as easy as you would like to believe or have the rest of us believe. At least it will be easier for them to PORT to the new hardware and software, given the NeXT development environment, but it will NOT be trivial. It sounds like you have never done a major port! How are developers tuning their apps for the 68040? NeXT has some work to do, but most developers don't have much work at all! They can build 68040 and 88K (or any other chip) binaries from a single source. Possibly the same source they're using today. -Mike From news Sun Aug 5 21:42:17 91 From: bob@MorningStar.Com (Bob Sutterfield) Subject: Re: New NeXT's in November? In article melling@cs.psu.edu (Michael D Mellinger) writes: In article <3160@pdxgate.UUCP> a0cb@.cc.pdx.edu (Chris Bertholf) writes: ...Especially if [VARs and secondary software developers] have tuned their application(s) to the current hardware. How are developers tuning their apps for the 68040? Usually without much effort at all. It's very easy to write code that runs well on one type of processor architecture. The hard work comes in writing very portable code without any assumptions about the underlying iron. NeXT has some work to do, but most developers don't have much work at all! It depends upon how much work the developers did up front to make their code portable. If they're experienced in writing code to run on a variety of processors, then their code is probably already most of the way there. If they have only worked on one or two types of machines, then they may discover a lot of hidden assumptions. Not to sound snooty or anything, but how many NeXT developers came "up" from (e.g.) Macintoshes, and how many came "down" from other UNIX systems? The former group has been living in a sheltered, forcibly homogenous world, where the biggest shock in recorded history was the introduction of Color QuickDraw and 32-bit addressing, which wouldn't have bothered any of them if they had been writing portable code in the first place. The latter group has seen it all before, and will have a much easier time of it. They can build 68040 and 88K (or any other chip) binaries from a single source. Possibly the same source they're using today. Yes, they can, if the code is well written. But the toughest time in any UNIX code's life cycle is typically its first port to a RISC architecture. I've ported "super-portable" code that was written on a VAX to a Sun-1 and a Sun-2 and a Pyramid, and from a Sun-1 to a Sun-2 to a Sun-3 to a Sun-4, and from several other things to 88K and MIPS and IBM RTs and RS/6000s. It's uniformly harder to move from a CISC machine to a RISC machine, because the RISC machines are uniformly pickier. If the author isn't careful about the original assumptions about (e.g.) byte ordering and structure packing and array index incrementing efficiency (row vs column), it can sometimes be easier to pitch the code and rewrite it all from the specs. If they still exist. From news Sun Aug 5 22:11:53 91 From: a0cb@.cc.pdx.edu (Chris Bertholf) Subject: Re: New NeXT's in November? In article you write: > >In article <3160@pdxgate.UUCP> a0cb@.cc.pdx.edu (Chris Bertholf) writes: > > Try to tell VARs and secondary software developers this. Especially if > they have tuned their application(s) to the current hardware. Sure, it > is 1991, but it is not as easy as you would like to believe or have the > rest of us believe. At least it will be easier for them to PORT to the > new hardware and software, given the NeXT development environment, but > it will NOT be trivial. It sounds like you have never done a major port! > > >How are developers tuning their apps for the 68040? NeXT has some >work to do, but most developers don't have much work at all! They can >build 68040 and 88K (or any other chip) binaries from a single source. >Possibly the same source they're using today. In many cases this is true, but it is NOT true in many other cases. Have you ever ported a large application before? Have you ever written a large app before--One which REQUIRED the use of assembly level programming for time critical apps or specialized optimization? In my experience, even moving apps from one BSD 4.3 system to another BSD 4.3 system (both may be variants) are not always as simple and straight-forward as you imply. What if large portions of the optimized software I write is assembly for the 68040. I suppose you think that this would require a minor port to the 88K. I don't think so. Nor do many other independent software developers. Believe it or not, many time critical and specialy optimized pieces of code are STILL WRITTEN IN ASSEMBLY LANGUAGE. Of course if you have some special tool that will migrate 680x0 assembly to 88K assembly transparently and without programmer intervention, I think a lot of people might become real interested (if NeXT moves to an 88K platform). I'd be one of them. Chris __ / ) / / /_ __ o _ (__/ / /_/ (_<_/_)_ From news Sun Aug 6 05:47:06 91 From: rgc@risky.med.jhu.edu (Ross G. Cutler) Subject: Re: New NeXT's in November? In article <3166@pdxgate.UUCP> a0cb@psuorpn.UUCP (Chris Bertholf) writes: [stuff deleted] >developers. Believe it or not, many time critical and specialy optimized >pieces of code are STILL WRITTEN IN ASSEMBLY LANGUAGE. Admittedly, some stuff is written in assembly for speed, but how many NeXTstep Apps are? That is the real question... My guess is that virtually none use assembly (except for some DSP stuff). In all of the NeXT PD source code that I've looked through in the archives, I haven't see one line of 68000 assembly code. NeXT doesn't want people to use assembly, and this is reflected in the total lack of documentation for as(1). Personally, I think this is a Good Thing, even though I use assembly myself (for hacks only). In summary, I don't foresee any big problems in porting large applications (e.g. Improv, WP, Diagram), since I doubt very much that any of these packages have any assembly code in them at all. Ross. From news Sun Aug 6 14:14:59 91 From: kari@finn (Kari Karhi) Subject: Re: New NeXT's in November? In article <1991Aug6.054706.21642@boingo.med.jhu.edu> rgc@risky.med.jhu.edu (Ross G. Cutler) writes: > Admittedly, some stuff is written in assembly for speed, but > how many NeXTstep Apps are? That is the real question... My guess is co-Xist server uses some asm() calls that are mc680x0 specific. From news Sun Aug 6 18:07:06 91 From: a0cb@.cc.pdx.edu (Chris Bertholf) Subject: Re: New NeXT's in November? In article <1991Aug6.054706.21642@boingo.med.jhu.edu: rgc@risky.med.jhu.edu (Ross G. Cutler) writes: I seem to remember that EDIT and several other apps were written in assembly. Just because you have not found any assembler in the marginally helpful, generally small pieces of software on the archives does not mean that the proprietary apps don't have them. Try porting code from a CISC to a RISC. If you have not taken the UTMOST care to make the code portable, it is a bitch... It doesn't even have to be assembly language we are talking about. Many programmers make incorrect assumptions about a variety of things (bit operations, bit fields, byte ordering, to name a few) that make it very difficult to port from a CISC to a RISC, or even to another different CISC. In addition, Who says that these developers only want to develop for the NeXT. With the new SGI boxes, people may want to write portable apps for both boxes. Multimedia apps. Do that in a portable fashion. Especially graphics and sound... Oh, and don't use any assembly for the processors that do not even have C or other language compilers. Chris __ / ) / / /_ __ o _ (__/ / /_/ (_<_/_)_ From news Sun Aug 6 19:43:30 91 From: rgc@risky.med.jhu.edu (Ross G. Cutler) Subject: Re: New NeXT's in November? [stuff deleted] In article <3175@pdxgate.UUCP> a0cb@psuorpn.UUCP (Chris Bertholf) writes: > >I seem to remember that EDIT and several other apps were written in assembly. >Just because you have not found any assembler in the marginally helpful, >generally small pieces of software on the archives does not mean that the >proprietary apps don't have them. How do you know Edit was written in Assembly? Did you see the source? It doesn't make any sense to me that it would be. In fact, if you type otool -v -o /NextApps/Edit you can see that there are lots of custom Obj-C files. I could not find any traces of *.s files in Edit; it is possible that some assembly was used... but I highly doubt it. GCC is a very good compiler, and produces very good code. And since the NeXT is damn fast (as least as far as apps like Edit is concerned), why would any programmer taint his OOP code with assembly? Ross. From news Sun Aug 6 22:36:22 91 From: a0cb@.cc.pdx.edu (Chris Bertholf) Subject: Re: New NeXT's in November? In article <1991Aug6.194330.28967@boingo.med.jhu.edu> you write: >[stuff deleted] >In article <3175@pdxgate.UUCP> a0cb@psuorpn.UUCP (Chris Bertholf) writes: >> >>I seem to remember that EDIT and several other apps were written in assembly. >>Just because you have not found any assembler in the marginally helpful, >>generally small pieces of software on the archives does not mean that the >>proprietary apps don't have them. > >How do you know Edit was written in Assembly? Did you see the source? >It doesn't make any sense to me that it would be. In fact, if you type > > otool -v -o /NextApps/Edit > >you can see that there are lots of custom Obj-C files. I could not find any >traces of *.s files in Edit; it is possible that some assembly was used... >but I highly doubt it. GCC is a very good compiler, and produces very good >code. And since the NeXT is damn fast (as least as far as apps like Edit is >concerned), why would any programmer taint his OOP code with assembly? Well, I might be wrong, but then the thread about EDIT originally being written in MOSTLY assembly that occurred in reference to another thread on comp.sys.next should have drawn a little more heat than it did... How do you know that large portions were not written in assembly? Did you see the source? Another Poster has pointed out that CoXist has several assembly hacks to get the job done... I was just pointing out one app that I heard had some major assembly work in it... I find it interesting that you say "taint", when most or all of the programmers and application developers I know tend to optimize and write time critical apps with combinations of C *AND* assembly. Have you ever written real time apps, time critical apps, or done your own optimization? (No, the -O option does not count) In addition, the argument about GCC producing tight code doesn't apply. GCC will have to be reworked to *EFFECTIVELY* support the 88K RISC processor. RISC is not CISC. The techniques for efficient compilers on a RISC box are very different than those for CISC boxes. The compiler has to make use of the pipelines and superscalar architecture of the RISC chip, in addition to the register allocation problems and the limitations of addressing memory directly versus through the cache. Why do you think IBM has a 37% improvement in SPECmarks without changing the clock speed of the RS/6000s, only the compilers were changed... BTW, IBM does not share all of its optimization techniques with the rest of the world--some are patented proprietary information that the GNU project will not have access to... RISC is only as good as the compilers that produce code for the RISC chip. Poor compiler technique can result in a RISC that has a phenomenal MIPS and MFLOPS rating, but can't outcompute an a 68K apple. Chris __ / ) / / /_ __ o _ (__/ / /_/ (_<_/_)_ From news Sun Aug 7 00:17:50 91 From: rgc@risky.med.jhu.edu (Ross G. Cutler) Subject: Re: New NeXT's in November? In article <3183@pdxgate.UUCP> a0cb@psuorpn.UUCP (Chris Bertholf) writes: [stuff deleted] >Well, I might be wrong, but then the thread about EDIT originally being >written in MOSTLY assembly that occurred in reference to another thread >on comp.sys.next should have drawn a little more heat than it did... >How do you know that large portions were not written in assembly? >Did you see the source? Another Poster has pointed out that CoXist has >several assembly hacks to get the job done... I was just pointing out one >app that I heard had some major assembly work in it... > >I find it interesting that you say "taint", when most or all of the >programmers and application developers I know tend to optimize and >write time critical apps with combinations of C *AND* assembly. Have >you ever written real time apps, time critical apps, or done your >own optimization? (No, the -O option does not count) > >In addition, the argument about GCC producing tight code doesn't apply. >GCC will have to be reworked to *EFFECTIVELY* support the 88K RISC >processor. RISC is not CISC. The techniques for efficient compilers >on a RISC box are very different than those for CISC boxes. The >compiler has to make use of the pipelines and superscalar architecture >of the RISC chip, in addition to the register allocation problems >and the limitations of addressing memory directly versus through >the cache. Why do you think IBM has a 37% improvement in SPECmarks >without changing the clock speed of the RS/6000s, only the compilers >were changed... BTW, IBM does not share all of its optimization >techniques with the rest of the world--some are patented proprietary >information that the GNU project will not have access to... > >RISC is only as good as the compilers that produce code for the RISC >chip. Poor compiler technique can result in a RISC that has a phenomenal >MIPS and MFLOPS rating, but can't outcompute an a 68K apple. Sure, I've done lots of 286 assembly work with C, including realtime work. I even wrote an entire Core-like graphics library in assembly for C, because speed was of the utmost importance. But that was then, on on relatively slow computers...now we have Objective-C and a relatively fast computer. You don't *need* assembly for applications like Improv or Adobe Illustrator. And the NeXT *isn't* realtime (we still use PCs for that...). I said "taint" because OOP is very *high* level, and assembly is very *low* level. You say you program in "C and assembly"; currently, I do most of my programming in Objective-C (or C++). OOP is what the NeXT is about. Assembly isn't. That's why it isn't supported at *all*. Finally, GCC is available on at least two RISC computers, namely the Sun SPARCstations (SPARC CPU) and the DEC DECstations (MIPS R2/3000). It might be availably for the PS/6000 and Snakes too. So NeXT is not starting from scratch (i.e. your CISC != RISC statement isn't very relavent). Ross. From news Sun Aug 7 00:11:18 91 From: sef@kithrup.COM (Sean Eric Fagan) Subject: Re: New NeXT's in November? In article <3183@pdxgate.UUCP> a0cb@psuorpn.UUCP (Chris Bertholf) writes: >In addition, the argument about GCC producing tight code doesn't apply. >GCC will have to be reworked to *EFFECTIVELY* support the 88K RISC >processor. It already has been. Gcc-2 (still in alpha, "Soon" to be beta) has a lot of features to work well on a RISC machine, including the 88k. >RISC is not CISC. The techniques for efficient compilers >on a RISC box are very different than those for CISC boxes. Not much. That's one of the interesting things about CISC vs. RISC: someone once made a compiler only use the "simple" instructions on a VAX (including simple addressing modes), and benchmarked the output with the output of the unmodified compiler. Result: the RISC-based approach was faster. (I really wish I could remember where this was; I'm pretty sure it was in a UseNIX paper within the past two or three years.) Code generation that produces fast code on a '40 is going to pretty much do the same thing on an 88k (remember that the complex addressing modes on the '40 are slower than the "simple" ones). >BTW, IBM does not share all of its optimization >techniques with the rest of the world--some are patented proprietary >information that the GNU project will not have access to... Uhm, most of the stuff IBM is doing is pretty obvious to people writing compilers. As I said, gcc-2 is no slouch on RISC machines (I've been told that it outperforms most other compilers for the Sparc, including Sun's; I don't have any figures, though, so that's just anecdotal). >RISC is only as good as the compilers that produce code for the RISC >chip. So is a CISC chip. Sheesh. From news Sun Aug 7 01:30:48 91 From: melling@cs.psu.edu (Michael D Mellinger) Subject: Re: New NeXT's in November? <3175@pdxgate.UUCP> <1991Aug6.194330.28967@boingo.med.jhu.edu> <3183@pdxgate.UUCP> In article <3183@pdxgate.UUCP> a0cb@.cc.pdx.edu (Chris Bertholf) writes: In addition, the argument about GCC producing tight code doesn't apply. GCC will have to be reworked to *EFFECTIVELY* support the 88K RISC processor. RISC is not CISC. The techniques for efficient compilers on a RISC box are very different than those for CISC boxes. The compiler has to make use of the pipelines and superscalar architecture of the RISC chip, in addition to the register allocation problems and the limitations of addressing memory directly versus through the cache. Why do you think IBM has a 37% improvement in SPECmarks without changing the clock speed of the RS/6000s, only the compilers were changed... BTW, IBM does not share all of its optimization techniques with the rest of the world--some are patented proprietary information that the GNU project will not have access to... GNU GCC has already been ported to the 88K. Data General has been using it for quite some time. Compiler technology plays a *very* important role in RISC processors. RISC is only as good as the compilers that produce code for the RISC chip. Poor compiler technique can result in a RISC that has a phenomenal MIPS and MFLOPS rating, but can't outcompute an a 68K apple. We already know this. RISC isn't exactly new. There are just a few workstation vendors that haven't made the move to RISC yet. NeXT, and ... that's all I can think of. GCC 2.0 will be in out sometime in the next several months and it will include many improvements in the optimizer, especially ones for RISC processors. The FSF claims that it's as good (or comes close?) to Sun's commercial compiler for generating Sparc code. -Mike