Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!cuuxb!ltuxa!ll1a!spl1!laidbak!daveb From: daveb@laidbak.UUCP (Dave Burton) Newsgroups: comp.lang.c Subject: Re: Portable "asm" <-- portable? since when? Message-ID: <1355@laidbak.UUCP> Date: 6 Mar 88 03:18:06 GMT References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <7401@brl-smoke.ARPA> <697@l.cc.purdue.edu> Reply-To: daveb@laidbak.UUCP (Dave Burton) Organization: is pretty bad/My method of Lines: 68 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?). |... 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. 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. Do *not* mix languages in a single source file. |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. 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. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include Naperville, IL 60540