hrubin@osupyr.UUCP (Herman Rubin) (05/05/87)
In article <757@instable.UUCP>, amos@instable.UUCP (Amos Shapir) writes: > In article <685@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: > >I kinda suspect this is one of the big reasons that many people think that > >assembly programming is difficult: the assembler software they're using is > >terrible. > > So, people do not like assembler because they have no macros - ok, let's > give them named macros to name their constructs, and macro libraries, > and why not recursive macros so they can use nested IF/WHILE macros - > and Voila! you have created an almost HLL syntax, but unlike a 'real' > HLL, the generated code is ugly and inefficient, and you do not have the > security of type checking. > > Amos Shapir > National Semiconductor (Israel) > 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. (972)52-522261 > amos%nsta@nsc.com {hplabs,pyramid,sun,decwrl} 34.48'E 32.10'N Both of these posters miss the point. I do not object to typing, but I do to strong typing. The macro processors that I have seen are inadequate. I would like x = y - z to be a macro, where the translation into the appropriate code would depend on the types of x, y, and z. However, I should be able to override this if I, the person who knows what I am trying to do, think it appropriate. I want to be able to be able to use such constructs as multiple words, multiple word shifts, condition codes (including overflows), etc. I may even have to introduce additional macros, such as a triple word shift or an alternative to it on machines which require even-odd register pairs. I should be able to specify the k-th most significant word or byte of a multi-unit construct without having to worry whether the machine is little or big endian when that can be done. I know the benefits and dangers of using boolean operations on floating point numbers, and know that machine dependence is frequently necessary to get any efficiency. As for the generated code being ugly and/or inefficient, there are few cases in which compilers have produced code which is any better than the way I would code the problem. I am not against compilers and HLLs provided they allow the programmer to easily override the bad code they produce. Also remember that the cost of subroutines is high and the cost of transfers is not low; the cost of memory references is also not too good. I think a fair compiler/ assembler can be produced. I also believe that anyone who attempts to produce a good language/compiler/assembler can only produce a bad product. All mankind does not know enough to restrict the intelligent programmer; the current attempts only brain-damage. -- Herman Rubin Until mid May: Department of Statistics, Cockins Hall, 1958 Neil Avenue Ohio State University, Columbus OH43210 hrubin@osupyr or cbosgd!osu-eddie!osupyr!hrubin or ts0474@ohstvma.bitnet "Permanent": Department of Statistics, Purdue University, West Lafayette IN47907 hrubin@l.cc.purdue.edu or ihnp4!pur-ee!stat-l!hrubin or hrubin@purccvm.bitnet