Portable "asm" <-- portable? since when?

[MH Cox]

In article <1355 at laidbak.UUCP> daveb at laidbak.UUCP (Dave Burton) writes:
>In article <697 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
>|In article <7401 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>|> In article <2738 at mmintl.UUCP> franka at 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 at 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
==========================================================================