Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!utah-gr!uplherc!esunix!bpendlet From: bpendlet@esunix.UUCP (Bob Pendleton) Newsgroups: comp.arch Subject: Re: Software Distribution Message-ID: <963@esunix.UUCP> Date: 31 Aug 88 15:28:06 GMT References: <1988Aug29.202603.13897@utzoo.uucp> Organization: Evans & Sutherland, Salt Lake City, Utah Lines: 91 From article <1988Aug29.202603.13897@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): > In article <958@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes: >>... The general rule is that hardware >>dependent problems must be pushed through to the hardware dependent >>code generator... > > The trouble is that, in the real world, the part of the compiler that > does not make hardware-dependent decisions is the easy and small part. > The idea that parsing, type checking, etc. is a big deal is basically > an academic prejudice in favor of things that are easy to formalize. Some how I think I've just been called an academic. Perhaps because I mentioned some of my academic background in compiler writing. Oh well, if I didn't generaly agree with your opinion of academic compiler writers I wouldn't feel so offended. To make another academic reference, go way back into the literature and take a look at the Hearn, Griss LISP compiler. You might have to look for references to REDUCE to find the stuff. Their work indicates that ~90% of all optimization is architechture specific. They looked at register machines and stack machines and found that optimization was very dependent on whether you were targeting a stack machine or a register machine, but not on which specific register or stack machine. If you want examples of real world products that formalize code generation for complex machines, take a look at the ADA compiler from JRS, or the C compiler from QTC. Code generation can be formalized, and has been formalized. But, I think a lot of academics haven't noticed. The January 21, 1988 issue of "Electronics" has several articles on QTCs product. I don't know if JRS is publishing anything. > These things aren't trivial, mind you, but they're not the hard part > of a production-quality compiler. This is what brought on my comment > about the "intermediate" form being little more than tokenized source. Ok, I see what you're saying. Have you looked at the Ada Intermediate Language? I can't claim I've taken a close look, but it looks like the sort of thing we can expect to see. But, I still don't agree with you. There is a lot of machine independent optimizations that can be done on the intermediate form. There may also be a number of application dependent optimizations that can be done. > (Of course, this is > anathema to the Stallmanites... Don't expect GNU to support such a > portable distribution form.) Why not? If I have a generic machine running GNUix (I know its not called that), why should I be barred from buying a commercial software package? The Stallmanites may think its wrong to sell software, but why would they try to stop me from buying software if I want to? I just plain don't understand Stallman. From reading the GNU manifesto it looks like he's trying to tell me that hardware engineers and hardware companies have a right to sell what they produce, but software engineers and software companies don't. This seems just plain insane to me. If anyone wants to set me right on this, do it by private mail. Please don't clutter the net with it. > Standardizing the content is what we've been talking > about. I can see OSF doing either. Yes, I don't trust OSF, or AT&T/SUN as far as I can throw a UNIVAC 1108 core memory cabinet (had to do something to tie this into architectures), but I don't think the OSF member companies would be willing to give up their proprietary architecures. > And about whether the programmer was competent enough to make the code > really portable. Don't forget that condition. Since you haven't really > got source, you can't (readily) go in and fix it if there's a problem. > This new flexibility also opens the door to a whole new range of bugs, > since the code can now be run on machines which the author never even > compiled it on. Yep, look at the Ada experience for perspective on this problem. Thats why I described declarations in the intermediate form as constraints. The intermediate form is going to have to be full of constraints. If the program has a bunch of declarations that require 36 bit ones complement integers, you can be sure that it will run very slowly on a 68020. But, you can make it run without error if those contraints are available to the target machine code generator. I'll bet that a standard conforming implementation on a 68020 will be allowed to refuse to translate a program that is a gross missmatch for the target machine. Bob P. -- Bob Pendleton @ Evans & Sutherland UUCP Address: {decvax,ucbvax,allegra}!decwrl!esunix!bpendlet Alternate: utah-cs!esunix!bpendlet I am solely responsible for what I say.