Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU From: MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU Newsgroups: comp.lang.c Subject: Undelivered mail Message-ID: <12337@brl-adm.ARPA> Date: 13 Mar 88 02:36:59 GMT Sender: news@brl-adm.ARPA Lines: 54 Subject: Re: Portable "asm" <-- portable? since when? [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 9420 for SXJVK@ALASKA; Sat, 12 Mar 88 17:21 AST Received: by UWAVM (Mailer X1.25) id 6114; Sat, 12 Mar 88 18:21:23 PST Date: Fri, 11 Mar 88 22:10:17 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List From: Henry Spencer Subject: Re: Portable "asm" <-- portable? since when? Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella > 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