dan@Apple.COM (Dan Allen) (05/27/88)
In article <10893@apple.Apple.Com> dan@apple.UUCP (Dan Allen) writes: >After all, everyone should understand the native language that their >machine speaks.... I wrote this because I feel strongly that high performance applications need to use assembly language now and again. I wrote this because compilers (even the best) make mistakes that are sometimes VERY hard to find unless you look at--not the source code--but the object code that was generated. I wrote this statement NOT because I feel that every application should be written entirely in assembly, but because every application perhaps should be written in about 5% assembly. (Your mileage may vary) Look at apps like MacPaint and HyperCard: they use the 95% Pascal and 5% Assembly formula, with good results. Yes, yes, yes: high level languages are great, but in the end, IT ALL COMES DOWN TO ASSEMBLY LANGUAGE. My statement was to remind people that knowing some assembly language is both helpful and essential in a good computer scientist's toolkit of skills. Dan Allen Software Explorer Apple Computer
dorourke@polyslo.UUCP (David O'Rourke) (05/28/88)
In article <11093@apple.Apple.Com> dan@apple.UUCP (Dan Allen) writes: >Yes, yes, yes: high level languages are great, but in the end, IT ALL >COMES DOWN TO ASSEMBLY LANGUAGE. My statement was to remind people that >knowing some assembly language is both helpful and essential in a good >computer scientist's toolkit of skills. Thankyou for clearing that up. Now I agree with you! I little Assembly keeps the compiler away, and yes you can write VERY fast code. As long as it's done in moderation. Why didn't you say this in the first place? :-) -- David M. O'Rourke Disclaimer: I don't represent the school. All opinions are mine!
dan@Apple.COM (Dan Allen) (06/08/88)
In article <13735@comp.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes: >Please be careful of sweeping statements. Granted the 68000 is not the easiest >machine to compile code for and assembler is nearly always needed somewhere >in practice: >1) I would still rather see compilers improved to where they DID make assembler > redundant >2) Not all architectures require an assembler. There is no assembler on the > Burroughs (now Unisys) Large Systems. None. Never was. Ever. Not necessary. > All programming was done in Algol (or dialects.) > >Life is too short to spend it writing assembler. Perhaps your life is too short, but I choose to spend some of mine (not a lot, but some) writing assembly. (A person does not write assembler. An assembler is the tool, assembly is the language. We do not say, for example, "Life is too short to spend it writing compiler".) I write most of my Macintosh apps in Pascal, my MPW Tools in C, and my debuggers, INITs, and other small stuff in Assembly. I stand by my original statement that knowledge of a machine's native assembly language and architecture is very important to writing a good piece of code for that machine. Or at least a fast and successful piece of code. (Perhaps the use of the word good implies too much of a moral decision-)! Dan Allen Apple Computer
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (06/09/88)
In article <13735@comp.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes: >2) Not all architectures require an assembler. There is no assembler on the > Burroughs (now Unisys) Large Systems. None. Never was. Ever. Not necessary. > All programming was done in Algol (or dialects.) That's not quite true. If the Algol compiler is compiled with a special switch (e.g. for systems programming), you can write direct "assembly" language. Since the B5xxx/B6xxx machines were stack-based, the code looked a lot like Polish code. Also, for the real kernel hackers, there was a thing called ESPOL, which would normally be considered an assembly language. I wrote/modified compilers to run on the B5500. I needed to know assembly language. (surely you don't think there were intrinsic 'IF', 'CASE', etc. instructions on that machine). Marc Kaufman (kaufman@polya.stanford.edu)
dlw@hpsmtc1.HP.COM (David Williams) (06/10/88)
in:comp.sys.mac.programmer / dan@Apple.COM (Dan Allen) /writes: (grammatical stuff deleted) >I write most of my Macintosh apps in Pascal, my MPW Tools in C, and my >debuggers, INITs, and other small stuff in Assembly. I stand by my >original statement that knowledge of a machine's native assembly ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >language and architecture is very important to writing a good piece of ^^^^^^^^^^^^^^^^^^^^^^^^^ Gee, I'm glad I know the architecture of phones, toasters, typewriters and power drills so that I can use them properly and EFFECTIVELY ;) Actually compiler writers and OS hackers should know these things in order to implement faster, cleaner products. Applications programmers/designers should IDEALLY never have to resort to something as primitive as assembly code. If its too SLOW in a HIGHER level language, just means the HW/OS/COMPILER combination is not efficient enough or has serious design compromises built into it. Look at Apple, still refusing to use graphics coprocessors in this day and age. We just brute force the stuff thru the 68xxx for you!! If you are going to stay with Quickdraw, put it on a QuickDraw RISC chip and pump up the clock speeds. >code for that machine. Or at least a fast and successful piece of code. ^^^^ I'll buy that at least. Why not make the C/C++ compilers scream? >(Perhaps the use of the word good implies too much of a moral >decision-)! >Dan Allen >Apple Computer ---------- David Williams Hewlett Packard
james@utastro.UUCP (James McCartney) (06/10/88)
In article <13735@comp.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes: >Life is too short to spend it writing assembler. How about: Life is too short to wait for a program to execute that was written by someone who didn't know how to speed it up with assembly. --or-- Life is too short to wait for the next generation of super optimizing "no assembly necessary" compilers to hit the market. Besides, some of us can't resist getting our hands dirty. :-) ---- James McCartney ----
newbery@rata.vuw.ac.nz (Michael Newbery) (06/10/88)
Alas, I must confess to being intimately acquainted with the intricacies of B6700 machine code, so I guess my arguments against knowledge of the underlying machine structure sound hollow. I have also in the past written a lot of assembly language for various machines. I even confess to ENJOYING so doing---the thrill of shaving a few cycles off a loop is VERY seductive. Nevertheless I don't think it is 'better' (moral stance?) to use high level languages as much as possible: it minimises the pain when the Mac IV comes out with an 88000 fer instance ;-) I think it would be far better if MPW Pascal & C were highly optimising compilers so that I did not have to bypass the compiler and hand code critical bits. Re the B6700 compilers, ESPOL was just another dialect of Algol, it enabled you to do anything you could do in assembler, but it wasn't an assembly language. I suppose I would have to agree that knowing machine code is valuable, I favour the holistic approach to programming---the more you know, the better. Just be aware that things can go wrong, 68000 code that runs slower on the 68020 because it's too big to fit in cache for instance.
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (06/10/88)
In article <6884@cit-vax.Caltech.Edu> chi@tybalt.caltech.edu (Curt Hagenlocher) writes: >one major reason for this is the fact that the Mac's OS is written in >machine code, and Suntools is (as I just learned from the quoted article) >written in (probably) C. If you've used both, you'd appreciate the >difference. >I think that the availability of faster and faster machines has made >programmers sloppier. This refusal to deal with machine code is just >one aspect of that trend. When I had the opportunity (I owned the company) I required my programmers to use C exclusively (except for the interrupt kernel). If they complained about the code speed in a particular construce, I added optimization to the compiler. The result, at the far end of the project, was maintainable code that was nearly as fast as assembly code. Not everyone is willing or able to do compiler optimizer hacking... but it pays off. Marc Kaufman (kaufman@polya.stanford.edu)
mdc@mcp.entity.com (Marty Connor) (06/10/88)
In article <17030002@hpsmtc1.HP.COM>, dlw@hpsmtc1.HP.COM (David Williams) writes: > Gee, I'm glad I know the architecture of phones, toasters, typewriters and > power drills so that I can use them properly and EFFECTIVELY ;) Kinda unfair. The average quiche-eating person probably doesn't care about the inside of hir toaster. Of course, one may not make hir "bread and butter" using a toaster (sorry, couldn't resist). How about this. I would make the argument that one could be a BETTER race car driver if one had some idea of what went on inside one's car. Now the word BETTER is open to some interpretation. I mean, that there I am, stuck in the middle of the outback with a busted radiator hose, and with the tools in my trunk, and yet I can't fix it, because, "I'M NOT A MECHANIC, DAMN IT!!!". I hope you see the point. Sure, as long as you never want to look under the hood, you can just say, "I put the pedal to the metal and it doesn't go fast enough, where's Joe the Mechanic? What do we pay this guy's dental plan for anyway??? Is he on BREAK AGAIN??? I'll call you back, must be entering a new Cell...". > Actually compiler writers and OS hackers should know these things in order to > implement faster, cleaner products. "Engines are SOOO dirty...". Well, I would argue that there are GOOD reasons for more than just Systems Hackers to learn assembler. Now, in all fairness I should say that I am busy learning 68000 assembler currently. Mostly so that I can understand the machine better and have a chance to fix things like COMPILER BUGS and get some insight into my own bugs. (and hang out with my friends without the severe embarassment of not knowing what 'LINK A6,#0' and 'StAck DiSciPliNe' (note StUdLy CapItaLIzAtIon[tm]) are. I don't say everyone should learn assembler, (just everyone that I want to know...) [that was a J-O-K-E, alright, a JOKE!] I understand your point, and I hope you see mine. > David Williams > Hewlett Packard Regards, -- ---------------- Marty Connor Director of Innovation, The Entity mdc@mcp.entity.com, ...{harvard|uunet}!mit-eddie!spt!mcp!mdc
dan@Apple.COM (Dan Allen) (06/10/88)
The suggestion has been made that rather than using assembly language we should just make fast compilers. Agreed. They should be fast in compiling as well as generate fast code. These are great and noble goals which I have never seen realized. Of the compilers that I am familiar with, they always are generating wasted code like MOVE.W D1,D0 followed by MOVE.W D0,D1 and the like. They are (except for the Turbo Pascals of the world) always excruciatingly slow. They seem to offer little advantage over the problems of speed. What they do offer, of course, is a higher level of abstraction that is very important and desirable. I will retract my statement about the necessity of knowing assembly language when someone can show me a compiler that generates great code in a very quick turnaround. Until then I at least need to know and use assembly. Perhaps quick turnaround and good code are mutually exclusive and if that is true, then assembly will be here forever. And ever. Amen. (Apologies to Randy Travis) Dan Allen Apple Computer
earleh@eleazar.dartmouth.edu (Earle R. Horton) (06/11/88)
In article <11962@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: ... >(except for the Turbo Pascals of the world) always excruciatingly slow. >They seem to offer little advantage over the problems of speed. ... I don't know where you fellers at Apple get your compiler code from, but it has just got to be the slowest in the industry. To confound the problem, your engineers forgot to include some circuitry when they designed the Macintosh. I mean a real disk controller, DMA, nice stuff like that. Now, I realize they were trying to keep the price down, and I really appreciate that, but you have to admit that the lack of these components slows down the machine some. Despite the hardware limitations, some companies have managed to produce compilers which operate at near-light-speed, when compared with Apple products. (Now who could that be?) I'm not real familiar with Pascal, but a certain C compiler I am acquainted with just rips through my source code in the time it takes yours to parse <stdio.h>, seems like. I have heard that your compiler produces "better" code than this one; the only difference I can see is that MPW C likes to stuff variables into registers, while XXX C uses stack frames. Let me clue you in: THIS TRICK DOES NOT ALWAYS PRODUCE FASTER CODE. As far as I am concerned, neither one is real good because the software engineers left out the optimizer part of it, doubtless to reduce cost. (See previous paragraph.) What exactly do you mean by "except for the Turbo Pascals of the world?" You have this cumbersome, dinosaur-like compiler which doesn't even optimize, and you force it to run on this bargain-basement collection of deficient hardware, and you act surprised when someone else can do better. Hmmpphhh! G*d, I would like to see what a Mac with a real disk controller in it could do! >I will retract my statement about the necessity of knowing assembly >language when someone can show me a compiler that generates great code >in a very quick turnaround. Until then I at least need to know and use >assembly. Perhaps quick turnaround and good code are mutually exclusive >and if that is true, then assembly will be here forever. And ever. Amen. Now, don't get me wrong, I think assembly is real nice, and programming in hex can be fun, too. But while you have been extolling the virtues of assembly, others have been busily at work using it to produce GREAT compilers which produce "quick turnaround and good code" as you say. VMS compilers: The best in the industry. Fact, not opinion. Intel's PLM compilers: Fast? Real fast. Good code? Sure. (Pascal fans LOVE PLM because if its INCREDIBLY strict type checking.) hc C compiler for IBM RT PC: Faster and better than anything that ever ran on a Macintosh. Note here: The IBM RT PC cpu chip is in the same league as the 68020, but it has a whole lot more hardware wrapped around it than Apple ever dreamt of putting in one box. Could this have anything to do with compiler speed? You bet. Could compiler design have anything to do with it, too? Maybe... (The same folks who wrote hc have a Pascal compiler for this box, and I hear it's real nice, too. You should try it out.) Knowledge of assembly is an asset to any programmer, I will grant you that. But if a computer or system as advanced as the Macintosh cannot be programmed well without it, then the designers have made some fundamentally wrong assumptions. Not everyone who is a good or even a superb programmer has to know assembly or even the instruction set on the target machine. The fact that assembly is "needed" when programming the Macintosh is more a reflection of the lack of good compilers (and a haphazard interface to system calls) than it is of the virtues of assembly. Hey, I just realized something! What did you guys do with the MiniFinder? Should I really post this? Oh, hey! You only live once... ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************
gillies@uiucdcsp.cs.uiuc.edu (06/12/88)
Blindingly fast compilers are a pretty new idea. I was genuinely shocked
to see brand XXX v2.15 compile at hundreds of lines per second. I
even spent a few minutes setting up a ram disk to push the compiler to
1000 lines per second. I'm supposed to know what's possible in computer
science, but these new "Turbo" compilers run at impossible speeds.
Perhaps we should redefine our notion of a World-class development
system to include two compilers: One, a blindingly fast
emit-NOPs-if-you-must compiler for prototyping. Another would be a
slow, methodical "build" compiler for recomputing the world when
you're done with the final product.
These two goals are fundamentally opposed -- it probably makes more
sense to write a separate compiler than to try to melt both functions
into one big monstrousity.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@cs.uiuc.edu}singer@endor.harvard.edu (Rich Siegel) (06/14/88)
In article <104700032@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: > >Perhaps we should redefine our notion of a World-class development >system to include two compilers: One, a blindingly fast >emit-NOPs-if-you-must compiler for prototyping. Another would be a >slow, methodical "build" compiler for recomputing the world when >you're done with the final product. Call me stupid, but I fail to see why you need two compilers. Why not just have an extremely fast compiler that generates better code than the competing compilers *AND* is FASTER than it's previous version? Then you can have your cake and eat it too: production-quality code and near-instant turnaround. --Rich "We want to have archaic and eat it too..." Rich Siegel Quality Assurance Technician THINK Technologies Division, Symantec Corp. Internet: singer@endor.harvard.edu UUCP: ..harvard!endor!singer Phone: (617) 275-4800 x305
palarson@watdragon.waterloo.edu (Paul Larson) (06/15/88)
In article <104700032@uiucdcsp>, gillies@uiucdcsp.cs.uiuc.edu writes: > Perhaps we should redefine our notion of a World-class development > system to include two compilers: One, a blindingly fast > emit-NOPs-if-you-must compiler for prototyping. Another would be a > slow, methodical "build" compiler for recomputing the world when > you're done with the final product. > > Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois > {gillies@cs.uiuc.edu} I know of at least one company which is already doing this. Watcom ships its advanced C6.0 compiler(for the DOS world) with Express C (apparently a very fast compiler with good debugging). Note: I don't work for these people, and I've never used their product. QuickC by Microsoft might be another example; I'm not sure how compatible it is with the Microsoft C 5.1. Johan Larson
freeman@spar.SPAR.SLB.COM (Jay Freeman) (06/15/88)
In article <4760@husc6.harvard.edu> singer@endor.UUCP (Rich Siegel) writes: >In article <104700032@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: > > Call me stupid, but I fail to see why you need two compilers. Why >not just have an extremely fast compiler that generates better code >than the competing compilers *AND* is FASTER than it's previous version? I believe that relatively simple compilers can run in time proportional to the number N of statements being compiled, but that certain non-simple classes of optimization require execution time that is O(N log N) or perhaps even O( N ** 1.5 ). If I am right, then for sufficiently large program size (probably that means "sufficiently large function size" in the case of C or of other languages that support completely independent compilation of functions), a "simple" compiler will compile arbitrarily faster than one which does these optimizations. Note also that if I am right, then if a software manufacturer truthfully states "our product will compile at the rate of N lines per minute", independently of program size, then that manufacturer is admitting to the world at large that the product CANNOT generate first-rate code. <canonical disclaimer -- these are personal opinions only>
kennel@minnie.cognet.ucla.edu (Matthew Kennel) (06/15/88)
In article <4760@husc6.harvard.edu> singer@endor.UUCP (Rich Siegel) writes: > > Call me stupid, but I fail to see why you need two compilers. Why >not just have an extremely fast compiler that generates better code >than the competing compilers *AND* is FASTER than it's previous version? >Then you can have your cake and eat it too: production-quality code >and near-instant turnaround. > >Rich Siegel >THINK Technologies Division, Symantec Corp. Yes, that would be nice, but in the best of all possible worlds we'd all have compilers that would remove bugs from our own programs etc. (a joke) Unfortunately it's not, shall we say, a 'trivial' problem. I can see a BIG problem with having two different compilers: they'd compile two slightly different versions of the language. A program that worked on one would not work on the other. Of course if all implmentations were strictly ANSI conforming and we never ever wrote slightly nonconforming code (we'd never do that would we) everything might be OK, but I wouldn't trust it. I think that a single compiler with various options in the code generator would be the most trustworthy solution. Someone mentioned that "it was a fact" that VMS compilers emit the best code: I agree that the VMS compilers that I've seen (Fortran and C) seem to produce very very good code, but they are certainly NOT especially fast in compiling. Interestingly, using the /NOOPTIMIZE switch on the fortran compiler did not make the compiler much faster: it gained maybe 10-15% but not much more. (These compilers with /NOOPTIMIZE probably produced better code than many other compilers I've seen already) Another problem with hard-core optimization is that it can make debugging much harder. If a compiler moves common sub expressions out of loops, for example, and if the instructions in question generate some kind of error, the unoptimized and optimized code might behave quite differently. The relationship between original source code and the object code gets more complicated and might make source-level debugging more difficult. (In fact, DEC recommends using /NOOPTIMIZE when using their debugger) So, there should always be a way to turn off optimizations---at least those that would make debugging difficult. (By optimization I don't mean non-braindamaged register allocation: that the compiler should do ``in its sleep'') I hope that Mr. Siegel isn't implying that his company's current product (LSC 2.15) provides "production-quality code and near-instant turnaround". I'll grant him the second, but their code is far from "production quality". Maybe people write real commercial programs with it, but that's because there's nothing better. I dunno; maybe all of the 68000 compiler gurus work for SUN. (Look at their compiler, hint hint) I don't mean to rag on LSC (I own a copy myself!) but I like everything about their compiler except the compiler. ====== I have a completely unrelating question that's been bothering me for a long long time. When one compiles a floating point program on a non 68881 macintosh one gets traps to the SANE package, right? And when one compiles for a Mac II one gets real '881 instructions, right? (in an accusatory voice--- "you do, don't you?") And if one runs that '881 code on a non FPP machine you'd get some trap, something like 'unimplemented instruction' or something like that, right? Then why doesn't the trap handler call the SANE package for '881 instructions? ISN'T THAT WHY MOTOROLA PUT THOSE TRAPS IN THERE IN THE FIRST PLACE????!!???? If this had been done 'in the beginning', all compilers could issue nice '881 instructions which would be emulated on Mac I's and would then scream on Mac II's without ANY change in software! Apple, can you hear? Even now, it's not too late to do it!---it could be easily included in a new System. And even if Apple doesn't want to admit their mistake I'm sure some other hackers could. (LSC 3.1?) The patch could even be a little INIT (I'm guessing); then the compiler could always produce '881 instructions. ====== How much optimization does LSC 3.0 do? I'm guessing that from the lack of advertizing hoopla (compare the Microsoft C 5.1 ads in PC rags) the answer is ``not much.'' Especially considering all the emphasis on the 'source-level debugger.' Yes, the debugger would be nice, but also imagine if every program were 35% smaller or faster.... (fade to dreamy setting) "Sure, Fullwrite will work in 1M!" "Debugger? No, you don't need any more memory!" (wake up in cold sweat) Matt Kennel
gillies@uiucdcsp.cs.uiuc.edu (06/15/88)
I'm no expert on compiler technology, but I think some of the most
powerful optimizing compilers build a parse tree in memory and then
apply all sorts of heuristic reorganizations to the tree. Also, some
small combinatorial register allocation problems can be solved on a
per-procedure basis (expensively). Furthermore, when you generate
machine code you probably want to do some peephole optimization. This
multiple-pass approach makes this type of optimizing compiler
fundamentally slow. For a quick turnaround compiler you want to read
a line of language, emit loader code, and move on, e.g. a single pass.
That's why I was suggesting that highly optimizing compilers are
fundamentally different from high speed compilers. If you remember
WATFOR and WATFIVE (some of the first quick turnaround FORTRAN
compilers ever written), these compilers purposely emitted bad code to
reduce turnaround time. I don't think you can have your cake and eat
it too.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@cs.uiuc.edu}alan@Apple.COM (Alan Mimms) (06/15/88)
I used to work for a company building an object-oriented programming environment based on Smalltalk-80, written ENTIRELY in C running on Apollo and Sun workstations. We got a copy of the (then very early beta-test) version of the GNU CC compiler and built it on our Sun 3/260 (24MHz 68020, I think) and recompiled our Smalltalk system using the resulting compiler. The results were ASTOUNDING! The system got almost 50% faster (than the version compiled with "-O" on the Sun compiler)! Also, it took quite a bit less time to compile the thing. This is with absolutely NO changes to the sources. Now, I don't want to start any flame wars concerning the Free Software Foundation and their compilers -- I personally applaud their commitment to quality software at no cost, but I know there are circumstances in which this has its problems. But the author of GCC does not hesitate to point out that his compiler is a memory HOG. Don't even try to run it on a machine without lots of virtual memory, he says... He's right. His compiler performs so well and is so powerful BECAUSE it uses lots of virtual memory for its very complete data structures, which have been designed to be efficient, but not at the cost of making the implementation of the optimizer difficult or complicated. He's trading off the human ability to handle complexity with the (at least at the time) ever-plummeting cost of computer memory. I believe that in the very near future, the industry will be able to return to the "memory is cheap" philosophy. Hopefully (governmental meddling willing), this time it will be permanent. The point I DO want to make is that efficient, optimizing compilers are VERY poorly understood beasties and that even large, well-funded companies don't necessarily do the job we know can be done. It frequently happens that a piece of complex software (e.g., an optimizing code generator for a compiler) must be written and there is NOONE available who has done one before! What is a software company to do, but to try educating the existing people and hope for the best? It is public knowledge that the MPW 2.0.2 C compiler was not written at Apple -- it is based on the GreenHills compiler, which (I THINK) is also being used on some other personal computers -- with a suitably modified code generator. Lightspeed C is a REMARKABLE product. It generates CORRECT and reasonably good code VERY VERY quickly and using (I believe, anyway) a fairly small memory. The advent of larger memory in most Macintoshes on a routine basis (which, as I said above, is likely to be soon) makes their choice not only reasonable, but economic. The memory manufacturers just haven't gotten their (considerably muddled) act together yet. When memory DOES get cheaper, and you can bet it will, THINK's choice will turn out to be an EXCELLENT one. Their product will again be the darling of the garage-shop software hacker. Give 'em a break. alan -- Alan Mimms My opinions are generally Communications Products Group pretty worthless, but Apple Computer they *are* my own... ...it's so simple that only a child can do it! -- Tom Lehrer, "New Math"
dorner@uxg.cso.uiuc.edu (06/16/88)
>I'm no expert on compiler technology, but I think some of the most >powerful optimizing compilers build a parse tree in memory and then >apply all sorts of heuristic reorganizations to the tree. Also, some > ... This >multiple-pass approach makes this type of optimizing compiler >fundamentally slow. ... Not only that, but by the time the optimizer is done messing with your code, it may have removed, re-ordered, or lipo-suctioned large sections of your program. This makes debugging from your source a wee bit confusing, whether done at source level or assembly level. >Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois > {gillies@cs.uiuc.edu} ---- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@uxc.cso.uiuc.edu UUCP: seismo!uiucuxc!dorner IfUMust: (217) 333-3339
dan@Apple.COM (Dan Allen) (06/16/88)
In article <13542@shemp.CS.UCLA.EDU> kennel@minnie.UUCP (Matthew Kennel) writes: > >When one compiles a floating point program on a non 68881 macintosh one >gets traps to the SANE package, right? And when one compiles for a >Mac II one gets real '881 instructions, right? (in an accusatory voice--- >"you do, don't you?") And if one runs that '881 code on a non FPP >machine you'd get some trap, something like 'unimplemented instruction' >or something like that, right? > >Then why doesn't the trap handler call the SANE package for '881 instructions? >ISN'T THAT WHY MOTOROLA PUT THOSE TRAPS IN THERE IN THE FIRST PLACE????!!???? > Unfortunately, this has been considered but rejected. I am not sure why it was rejected, but it does sound like the slick solution. The PACKages which implement the current software solution would have to be rewritten due to differences in argument sizes between software (80 bits) and hardware (96 bits). There is no completely uniform way of differentiating the various types of parameter passing that goes on. There is a grand total of one vector that ALL 881 calls would go through. The Handler would have to somehow disassemble the 881 instruction to figure out what it was going to do (say a FSQRT fp1,fp2 call), and then translate that into the appropriate PACK4 or PACK5 call, changing the parameter sizes, etc. It could be done, and may be a neat solution, but has not been done. Dan Allen Software Explorer Apple Computer
jwhitnell@cup.portal.com (06/16/88)
Rich Siegel writes... | Call me stupid, but I fail to see why you need two compilers. Why |not just have an extremely fast compiler that generates better code |than the competing compilers *AND* is FASTER than it's previous version? Sure, know of one? I don' think LSC qualifies, although the new version is suppose to be faster then the previous version (I'm still waiting for my upgrade, the check (and why no plastic?) went out yesterday), the code generated is adequate but not what I'd call production quality. I'll use it becuase otherwise it's the best compiler for the Mac (or any computer I've used), but I still want an optimizer in 4.0. BTW, unless Apple seriously broke the compiler they bought from GreenHills, MPW C should generate much better code the LSC. It's not faster because it uses 32 bit ints rather then 16-bit like LSC. -- Jerry Whitnell jwhitnell@cup.portal.com ..!sun!cup.portal.com!jwhitnell
earleh@eleazar.dartmouth.edu (Earle R. Horton) (06/16/88)
In article <12217@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: >In article <13542@shemp.CS.UCLA.EDU> kennel@minnie.UUCP (Matthew Kennel) writes: ... >>Then why doesn't the trap handler call the SANE package for '881 instructions? >>ISN'T THAT WHY MOTOROLA PUT THOSE TRAPS IN THERE IN THE FIRST PLACE????!!???? ... >Unfortunately, this has been considered but rejected. I am not sure why >it was rejected, but it does sound like the slick solution. ... >It could be done, and may be a neat solution, but has not been done. > >Dan Allen SANE can't emulate the 68881 now, I think Dan explained that pretty well. However, although the 68881 is a powerful processor, it should be possible to build a software emulator for it which runs on the 68000. I am not talking about traps to SANE here, I am proposing a full-blown 68881 emulator, and I have a suggestion about where to put it. There is 128k of useable ROM space on my Mac Plus, according to IM IV. There is also a pretty big chunk available on the SE, if you take out the pictures of the design team (sorry guys). Put the 68881 emulator code in the unused ROM space, along with some code to initialize it. Package the thing as "super-enhanced Macintosh FP emulator ROMs" and sell the thing for a fair, but still large profit, plus requiring dealer installation. Furthermore, tell all developers that they can assume a 68881 is always present. Everybody wins with this idea. Apple gets to sell a required upgrade to all 68000-Macintosh owners, developers don't have to worry about checking for a coprocessor, Plus/SE users get to stay in the game a little longer, and dealers get to charge whatever they want for plugging in two chips. Please do it? Earle R. Horton, Thayer School of Engineering, Hanover, NH I wouldn't mind dying -- it's that business of having to stay dead that scares the sh*t out of me. -- R. Geis
gillies@uiucdcsp.cs.uiuc.edu (06/16/88)
Re: Why doesn't SANE run when I invoke a 68881 opcode?
Q: Does the SANE package implement the same semantics as IEEE
standard floating point? If not, then perhaps it was a good
choice not to make them the same. I think they really are different
instructions.
Re: "What a headache it would be to use two separate compilers,
for they would compile two slightly different versions of the
same language"
A: 1. I don't think you have enough faith in language standards.
2. Furthermore, you don't have faith in language test suites.
3. Also, you don't have faith in language implementors.
4. Finally, the same problem crops up when you hit the -o (optimize)
switch on any given compiler with an optimizer?
The problem is solvable, just don't hire high school students to write
your compiler(s)! Much of the code (in particular, the parser
generator, the BNF, some symbol table implementation) could be shared
between two such compilers.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@cs.uiuc.edu}dan@Apple.COM (Dan Allen) (06/16/88)
In article <8915@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >the pictures of the design team (sorry guys). Put the 68881 emulator >code in the unused ROM space, along with some code to initialize it. The Mac Plus with its 128K of ROM space has virtually NO unused space in it. We squeezed in every bit of functionality we could into that 128KB. The Mac SE is a different story. Its 256KB ROMs do have a lot of wasted space, hence the pictures of the team in ROM. We really should have used it better, but there was no time to write, test, debug, and hone the code that would have filled up the ROM, so a two day hack of the photos was done. (Ever been under the pressure of getting a ROM burned months before the machine is supposed to ship???) One final thought on emulating the 68881: since the 881 uses a lot of the same addressing modes that the rest of the 68xxx family does, an emulator would have to disassemble or correctly emulate ALL of the 68xxx addressing modes, something that takes LOTS of code to do. Dan Allen Apple Computer
gillies@uiucdcsp.cs.uiuc.edu (06/17/88)
I think that when motorolla introduced the 68000, they also marketed an inexpensive ROM chip that did floating point. Was this floating point the same as that of the 68881 chip? If it was, I suppose Apple could have put the chip in their macintoshes. I have heard from an expert in floating point arithmetic (professor of a ph.d. student who designed the package for Apple) that Apple numeric packages are top-quality, and perhaps even better than the 68881. There are big differences between different floating point implementations, in round-off, precision, transcendental accuracy/convergence/speed.
gz@spt.entity.com (Gail Zacharias) (06/17/88)
In <12217@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: >In <13542@shemp.CS.UCLA.EDU> kennel@minnie.UUCP (Matthew Kennel) writes: >>Then why doesn't the trap handler call the SANE package for '881 >>instructions? > >It could be done, and may be a neat solution, but has not been done. Coral Common Lisp does exactly that i.e. it always uses 68881 instructions, and if running on a system without a 68881, it installs an f-trap handler which does the emulation using SANE. The handler really wasn't all that hard to write (even if it was way too hot that weekend...) -- gz@entity.com ...!mit-eddie!spt!gz Now let's all repeat the non-conformist oath.
alan@pdn.UUCP (Alan Lovejoy) (06/17/88)
In article <12256@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: >One final thought on emulating the 68881: since the 881 uses a lot of >the same addressing modes that the rest of the 68xxx family does, an >emulator would have to disassemble or correctly emulate ALL of the 68xxx >addressing modes, something that takes LOTS of code to do. Apple is not number one in the pc business, but number two. So Apple has to try harder. Does Apple want to be number one or doesn't it? Does Apple intend to be the best? Is Apple willing to spend the extra effort necessary to stay ahead of the competition? Seize your opportunities. Don't be lazy and rely on past work, the comepetition will make you pay for that mistake. The lack of hardware floating point in Apple's non-68020 boxes is a SERIOUS deficiency in at least one of the markets Apple wants to do well in: science/engineering. Even worse is paying for a Mac II but not being able to find appropriate software that uses the 68881. If Apple is serious about Desktop Engineering, they'd better fix this. -- Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida. Disclaimer: Do not confuse my views with the official views of Paradyne Corporation (regardless of how confusing those views may be). Motto: Never put off to run-time what you can do at compile-time!
grue@banana.cs.uq.OZ ( FROBOZZ ) (06/19/88)
In article <11962@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: >I will retract my statement about the necessity of knowing assembly >language when someone can show me a compiler that generates great code ^^^^^ ^^^^ >in a very quick turnaround. Until then I at least need to know and use ^^ ^ ^^^^ ^^^^^ ^^^^^^^^^^ I don't really see a need for both of these at once. A compilier that generates great code and a second compilier that has a quick turnaround would be sufficient. They would both have to be compatable, but they need not generate great code and be fast. You debug your program using the fast compilier, and then generate the final release version using the great compilier. Unfortunately, no compilier writers seem to think of this (:-() and us programmers suffer. --------------------- P. (my life is over) Dale grue@banana.cs.uq.oz --------------------- I am the Wizard. | The Wizard is me. | See ya, | SNIF | _________________ / grue@banana.cs.uq.oz
dee@cca.CCA.COM (Donald Eastlake) (06/20/88)
>In article <12256@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: >>One final thought on emulating the 68881: since the 881 uses a lot of >>the same addressing modes that the rest of the 68xxx family does, an >>emulator would have to disassemble or correctly emulate ALL of the 68xxx >>addressing modes, something that takes LOTS of code to do. I don't understand why you can't just use the 68xxx hardware to do this. I.E., couldn't you save a lot under most circumstances by contructing a 68xxx non-68881 instruction and executing it to fetch/store data rather than simulating the adressing mode steps? x x x x -- +1 617-969-9570 Donald E. Eastlake, III ARPA: dee@CCA.CCA.COM usenet: {cbosg,decvax,linus}!cca!dee P. O. Box N, MIT Branch P. O., Cambridge, MA 02139-0903 USA
jmunkki@santra.HUT.FI (Juri Munkki) (06/22/88)
In article <12256@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: >One final thought on emulating the 68881: since the 881 uses a lot of >the same addressing modes that the rest of the 68xxx family does, an >emulator would have to disassemble or correctly emulate ALL of the 68xxx >addressing modes, something that takes LOTS of code to do. Even the coprocessor makes the 68020 calculate the addresses. This means that you should be able to convert the addressing modes into LEA instructions. Of course a known subset of instructions would be better than nothing. Juri Munkki jmunkki@santra.hut.fi jmunkki@fingate.bitnet