Path: utzoo!mnetor!uunet!husc6!ukma!gatech!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.c Subject: Re: Portable "asm" <-- portable? since when? Message-ID: <703@l.cc.purdue.edu> Date: 8 Mar 88 12:31:17 GMT References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <1355@laidbak.UUCP> Organization: Purdue University Statistics Department Lines: 126 Summary: There is no way to insert modules; subroutine calls are expensive In article <1355@laidbak.UUCP>, daveb@laidbak.UUCP (Dave Burton) writes: > In article <697@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > |In article <7401@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > |> In article <2738@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > |> >Clearly, assembler statements should have been defined as: > |> >#asm > |> >instead of > |> >asm("statement"); > |> > |> A properly-designed system programming language should not have such > |> a feature at all. (It is not guaranteed in C, either.) > > What's all this about #asm < > ? > > First, #asm is really a way to change programming languages in > mid-stream. Second, kindly explain how #asm sections are portable? > Third, why not use separate assembly modules instead? If you _really_ need > the flexibility of assembly to do low-level programming, use an > assembler. I can see no need to mix assembly and C at the C source > level (why was the language designed in the first place?). Frankly, I believe that if someone developed a decent high-level, overloaded operator, reasonable syntax assembler it would have a good chance of supplanting C. Add the other useful features of C and you have a good language. Suppose that you have a situation in a program where the implementation of your compiler has done something bad, like use 10 instructions and 6 memory references where 2 instructions and no memory references can do the job. The overhead of a subroutine call is likely to be more than what can be saved; a goto construction may not work if part of the problem is that the compiler will mess up register use (very common). Also some of the very simple hardware operations which are useful for some problems have not been anticipated by the language developlers. This is so often the case for simple operations frequently found in hardware. More machines have a hardware operation &~, which most mathematicians normally use \ for, than have the operation &. I am more likely to want to use &~. If a programmer says that something is inline, and this should be a feature of any language, the compiler should at most point out why this is not good, but the judgment must be that of the programmer. > > |... Those who believe that the language gurus can > |_possibly_ anticipate how someone who understands the machine will want > |to do things are either totalitarian, ignorant, or stupid. > > Agreed. > Of course, you are not suggesting that Doug is one of these, are you? > > But let's go further on this point: > Those who believe that the language gurus can _possibly_ anticipate > how everyone (knowledgeable, ignorant, other) will want to do _any_ > thing are ... > > The language gurus themselves do not claim this. > A language is designed to perform a certain class of tasks - even the > class 'general', of which C is not a member. The language gurus may not claim this, but I am not so sure. The designers of 4.xBSD clearly state in their assembler documentation that the assembler is _not_ for programmers, but for compiler designers and system maintainers. All of the assemblers I have seen, with the exception of those designed for Cray-designed machines, use the atrocious prenex form with highly obfuscated ordering of arguments. In the early days of computers, this may have been necessary. I consider a programming language and an operating system to be a procedure whereby the user is enabled to more easily use the power of the computer. It is a great mistake to restrict a programming language. To even start to hope > that a non-machine specific language will produce *truly* optimal > code for other machine architectures is futile. Iff (not a typo) you > really must have use a machine's features for efficiency (which is > the point you argue [...understands the machine...]), drop down to that > machines optimal language, assembly. And do it in a file all by itself. But in too many cases, the existing HLLs may produce good code if small modifications are made. In many cases, these modifications are machine independent--I can give you cases of this. It may even be as simple as saying This is what is needed; implement this block efficiently, while maintaining its compatibility with the rest of the program. That is another reason for asm. > Do *not* mix languages in a single source file. See above. > > |I maintain that anyone who understands whatever computer is being programmed > |for will, without effort, see situations in which the HLL concepts (any HLL) > |are not the right way to do things. This should be encouraged; progress in > |programming should no be based on "thou shalt not do this because > | It can be done thusly (but not necessarily efficiently). > | It can get you into trouble. > | Why would anyone want to do this?" > > I disagree. You presume that this same individual also knows how the HLL > implements itself on that machine. This is not the case. Very few people > that know both the HLL and the machine instruction set will know what kind > of code the compiler will produce. Why not? > What do you mean by 'progress in programming'? > > True, it is unwise to place arbitrary restrictions upon a society > because the ruler-makers deem the masses incapable. (Follow this one > up to talk.flame, or wherever). In the context of programming, especially, > this has a deadening effect. However, for instructional purposes, a few > 'thou shalt nots' are highly beneficial. I see the results of students instructed by algorithms. Admittedly, these are not CS algorithms, they are mathematics algorithms. I find that most of them seem incapable of understanding the few simple concepts behind the algorithms. I believe that this applies to computing as well. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet