CompuServe Messages

Marcus, I have _no_ objection to the mixing of asm and C. I do feel that the mixing should only be done at module boundries, however. I've written a great deal of mixed code myself – probably more than the majority of Amiga developers, although I am of course guessing. I'm perfectly comfortable in asm, and in fact it was all I worked in up until about 7 years ago, having tossed the early "high level" languages out as unusable for performance applications. As for the user deciding rather than the compiler… sure. Sounds great to say that. Do you want your compiler to include apl parsing, with the decision left up to the programmer as to whether to include APL in the current module? #apl $#(*%($@*%&$#(&% #endapl how about… #basic 40 GOSUB 1100: GOSUB 2300: IF A>B GOTO 50 45 PRINT "HI MOM" 50 PRINT "HI DAD" #endbasic I mean, is it appropriate? These "features" would bring extra functionality – and confusion – and portability problems. One problem with any implementation of such a thing is that not all compilers have it – even on the same machine – and if they DO have it, then the underlying assumptions (registers, asm language, etc) may not be the same. K&R simply say that "some version "may" reserve the keyword asm" in the 1st book, and in the second book, the same line, unchanged appears in the reference. The 2nd book covers the ANSI version, in case you don't know that. Do you want to use a "feature" that is so nebulously defined? I don't – and I don't want to have to decipher it, either. If you need performance, write an asm module. Then you'll have it. If yo u need elegance, write a c module. I believe that mixing languages is best done at the link level. Then, in the form of the function calls, you at least have the definition of what the module is supposed to do. Inside a module, asm is a black mystery.