daveb@laidbak.UUCP (Dave Burton) (03/06/88)
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 <statement> |> >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 <disclaimer.h> Naperville, IL 60540
cik@l.cc.purdue.edu (Herman Rubin) (03/08/88)
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 <statement> > |> >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
cox@bentley.UUCP (MH Cox) (03/10/88)
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 <statement> >|> >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?). If the #asm has to come back, let's just revert to the old K&R style: #asm ; assembly goes here #endasm I agree with Dave whole-heartedly that we don't need yet another #asm (or to re-adopt the old style). It's against the "spirit" of the maxim, "Isolate your machine-dependent code." Now to change the subject and completely contradict myself... I *would* like to see the "interrupt" keyword added to ANSI C (or D). For a language to claim to be a system programming language and not provide the capability to write interrupt routines is a major oversight (although K&R seemed to do fine without it :-). Both Borland and Microsoft have added this capability, e.g.: interrupt int21() { } The function int21's address can now be placed in an interrupt vector to do interrupt processing. Although this is non-portable, it sure does make writing interrupt routines much easier. Also, I would like to see named access to specific CPU registers included in ANSI C, e.g. AX, BX, R0, R1, etc. Borland does a nice job of this by using _AX, _BX, etc as predefined variables for accessing CPU registers (from what I've heard about the ANSI standard (I don't have the latest copy), symbols beginning with underscore and in all capital letters are reserved for use by the compiler. So even with this CPU register "extension", Borland's compiler is still a "conforming" compiler! Maybe other compiler vendor's will follow suit (are you listenin' Microsoft ;-) and make CPU register access a common feature. I think with the combination of the "interrupt" keyword and CPU register access, that would eliminate 90% of the reasons for reverting to assembly langauge. >Do *not* mix languages in a single source file. Dr. Codd would disagree (see March 88 issue of _Computer Language_). What about SQL? I find C combined with embedded SQL and good forms and menu libraries to be one of the best application development environments going! -- ========================================================================== Michael H. Cox ARPA: moss!bentley!cox@rutgers.edu AT&T Bell Labs UUCP: don't know (can anyone help?) 184 Liberty Corner Road Rm 3B-Q15 Warren, NJ 07060 (201) 580-8622 ==========================================================================
henry@utzoo.uucp (Henry Spencer) (03/12/88)
> If the #asm has to come back, let's just revert to the old K&R style: > > #asm > ; assembly goes here > #endasm What "K&R" style?!? There is no "asm" or "#asm" in K&R. (It is mentioned once, in the Reference Manual, as a keyword reserved by some compilers.) > I *would* like to see the "interrupt" keyword added to ANSI C (or D). > For a language to claim to be a system programming language and not > provide the capability to write interrupt routines is a major oversight > (although K&R seemed to do fine without it :-)... This is a curious statement, given that all Unix's interrupt routines are written in C. There is a little bit of assembly-language glue involved on most machines, but all that does is smooth over differences in calling conventions. If you are willing to live with the idea that you can't just plop a function's address into an interrupt vector, but some small amount of mediation is required, no language change is necessary. It's not as if what you were doing was portable and could usefully be made standard across different implementations. (If you think it is, consider for example that my machine's interrupt vectors are structures, not just single pointers, so just filling in a function pointer is not enough.) > Also, I would like to see named access to specific CPU registers included > in ANSI C, e.g. AX, BX, R0, R1, etc... Subject to certain rules about naming conventions, ANSI implementations are free to provide whatever machine-dependent magic cookies they want. So are non-ANSI implementations, for that matter. Complain to your vendor if he doesn't do what you want. Actually *specifying* what should be done is so hopelessly machine-dependent and implementation-dependent that no standards committee in its right mind would put it into a standard. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
peter@sugar.UUCP (Peter da Silva) (03/12/88)
Here's one reason you might want to wrap assembly up into 'C'. Aesthetics. The sort of preface stuff you have to put into the typical assembly language module is truly ugly. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.