guido@boring.UUCP (11/02/85)
In article <1594@hammer.UUCP> tekecs!doghouse.TEK!snoopy writes: >What doesn't make sense is having a combination of compiler and lint >where one knows about void and the other doesn't. >(Sure it's *possible*, but WHY?) Well, for one thing, there need be only one lint, but there must be as many compilers as there are machines. For instance, I have a program which runs on the IBM-PC and is compiled there by a native compiler; to lint it, it use the lint on our 4.2BSD VAX, which is perfectly happy when you give it access to the PC's include files (and maybe add -Uunix -Uvax to the command line if the program has #ifdef unix or #ifdef vax lines in it). Lint's effect is (should be) independent of the machine; it checks static errors and portability issues, so there's no reason to match it to a particular compiler you're using (this will also teach compiler writers not to add non-standard syntax to the language, one of my major gripes against some Macintosh C compilers!). Please, no flames about there being no standard; that's being worked on. -- Guido van Rossum, CWI, Amsterdam (guido@mcvax.UUCP)
tim@ISM780B.UUCP (11/08/85)
/* Written 9:12 am Nov 2, 1985 by guido@boring in net.lang.c */ particular compiler you're using (this will also teach compiler writers not to add non-standard syntax to the language, one of my major gripes against some Macintosh C compilers!). /* End of text from net.lang.c */ Some of the non-standard things are quite useful, and a Macintosh program that uses them is very likely to be doing things that are very Mac specific and unportable anyway, so what is wrong with them?
mikes@3comvax.UUCP (Mike Shannon) (11/18/85)
> > /* Written 9:12 am Nov 2, 1985 by guido@boring in net.lang.c */ > > particular compiler you're using (this will also teach compiler writers > not to add non-standard syntax to the language, one of my major gripes against > some Macintosh C compilers!). > > > Some of the non-standard things are quite useful, and a Macintosh program > > that uses them is very likely to be doing things that are very Mac specific > > and unportable anyway, so what is wrong with them? If the compiler supports "non-standard" syntax, then it is not a C compiler, it is a "something else" compiler. And it should be called something else. You won't get any complaints if you call your language "X", "Hacked C", "Monstrosity", or "Heaven". It's just that problems arise when people start thinking that the programs which the compiler compiles are actually C. One thing which many Unix compilers support is the 'asm' statement, that is: proc() { asm("mov r0, r1"); } the effect of the 'asm' procedure call is not to generate code. Instead, the string is passed 'directly' thru as assembly language in the generated output. This allows the programmer to generate assembly language directly. Not only is it machine specific, but it is also dependent on the optimizer in the compiler. I'd sure like to see someone defend this particularly disgusting (but supported on our 4.1bsd system) "feature"! -- Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes
peter@graffiti.UUCP (Peter da Silva) (11/21/85)
> Some of the non-standard things are quite useful, and a Macintosh program > that uses them is very likely to be doing things that are very Mac specific > and unportable anyway, so what is wrong with them? Unportable, yes... by definition. Mac-specific? No longer. See net.micro.amiga and net.micro.atari for more info. It is no longer acceptable to assume that windows==macintosh (actually it never was, but you slobs got away with it). -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
ps@celerity.UUCP (Pat Shanahan) (11/22/85)
In article <284@3comvax.UUCP> mikes@3comvax.UUCP (Mike Shannon) writes: ... > >One thing which many Unix compilers support is the 'asm' statement, that is: >proc() >{ > asm("mov r0, r1"); >} > the effect of the 'asm' procedure call is not to generate code. >Instead, the string is passed 'directly' thru as assembly language in the >generated output. This allows the programmer to generate assembly >language directly. Not only is it machine specific, but it is also >dependent on the optimizer in the compiler. > I'd sure like to see someone defend this particularly disgusting >(but supported on our 4.1bsd system) "feature"! >-- > Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes While I am not prepared to defend the use of "asm" in normal application or utility programming, I have maintained it in a C compiler port and added a minor enhancement, so I think I should defend its presence in the compiler. Any operating system has to have some functions that are highly machine dependent. The functions may manipulate the state of paging tables, or control I/O activity, or save and restore the process state. Some of these functions will have to be implemented entirely in assembly language. However, there are functions that can be implemented substantially in C, if the programmer can insert a small number of explicit assembly language statements. These functions often cannot be subdivided without an unacceptable performance overhead. Without the "asm" feature, these functions would all have to be implemented entirely in assembly language. With the "asm" feature, the programmer who is responsible for implementing a function can decide which language to use. I see a well-implemented "asm" as a tool for reducing the volume of assembly language code in the operating system. Similar situations can arise in diagnostics or timing measurement. I think that "asm" should only be used in functions that meet both of the following conditions. 1) The function is inherently machine-dependent, so that it would have to be re-written to port it to a substantially different machine. 2) The alternative to using "asm" is to write it entirely in assembly language. -- ps (Pat Shanahan) uucp : {decvax!ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ps arpa : sdcsvax!celerity!ps@nosc
tim@ISM780B.UUCP (11/22/85)
> One thing which many Unix compilers support is the 'asm' statement, that is: > proc() > { > asm("mov r0, r1"); > } . . . > I'd sure like to see someone defend this particularly disgusting > (but supported on our 4.1bsd system) "feature"! On the vax it is disgusting, because you can't do much unless you know how the compiler works. But some implementations of asm make it quite useful. For example, in Megamax C for the Macintosh, the asm statement works like this: asm { stuff }; /* don't remember if the ; is needed here */ Within the stuff, one may use the following constructs ( substitute your favorite instruction for "move" ) move foo, bar /* like C bar = foo; foo,bar are global */ move a6@(foo),a6@(bar) /* like above, but foo,bar local */ move d7,d6 /* foo and bar are first and second register variables in this function */ So I can write assembly code and access all my C variables. This has several advantages: 1. I don't need an assembler. I can just use C. Plus I get to use the C preprocessor on my assembly files this way. 2. I can profile my C programs ( they provide a profiler ), and rewrite the slow parts in inline assembly in a convienient and efficient way. 3. When doing assembly stuff, I can keep C control flow. Of course, this is machine dependent... Tim Smith ihnp4!cithep!tim ima!ism780!tim
lee@haddock.UUCP (11/24/85)
I think that "asm" should only be used in functions that meet both of the following conditions. 1) The function is inherently machine-dependent, so that it would have to be re-written to port it to a substantially different machine. 2) The alternative to using "asm" is to write it entirely in assembly language. I sometimes find an alternative to condition 1) along the following lines: 1a) the function is performance sensitive and can be significantly improved in performance on a particular architecture by insertion of small amounts of inline assembly code. For example, the operation performed by the IBM 370 "tr" instruction or the VAX "movtc" instruction can replace a loop in critical sections of otherwise ordinary C code. In these cases, of course, the asm() directive containing FOO assembly code should be embraced in "#if defined(foo)" and the equivalent C code compiled for architectures for which the asm() directives are not provided.
tim@ISM780B.UUCP (11/26/85)
> See net.micro.amiga and net.micro.atari for more info. It is no > longer acceptable to assume that windows==macintosh (actually it > never was, but you slobs got away with it). Are you saying my Mac programs should easily port to the Amiga, the Atari 520ST, the Sun , V8 Unix ( if you have a BLIT ), System V ( if you have a Teletype 5620 ), the IBM PC and Clones ( with GEM ), the AT&T PC7300, and a few random Xerox machines? They all have windows. Tim Smith ihnp4!cithep!tim ima!ism780!tim