Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c
Subject: Re: Portable "asm" (Was: The D Programming Language)
Message-ID: <686@l.cc.purdue.edu>
Date: 22 Feb 88 12:56:20 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <4257@june.cs.washington.edu>
Organization: Purdue University Statistics Department
Lines: 34
Keywords: portable D
Summary: If we do asm right, there is no problem

In article <4257@june.cs.washington.edu>, pardo@june.cs.washington.edu (David Keppel) writes:
> In article <915@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
> >>  - we should assume that compilers for this language are going to
> >>    do a great deal of optimisation; in particular, they will optimise
> >>    across entire compilations, not just single files.
> >
> >    Which brings up a question, what happens to the asm statement then.
> >If you have the write you code such that you have no idea
> >where variables are stored, how can you reliable use assemble statement
> >that play with storage.  I think the conclusion will be trash asm.

If we have the compiler replace names by locations (register and/or memory)
of the variables used, there is no more problem with global optimization
than before.  In fact, we should do this in C; it is not prohibited by the
language standards, and it certainly makes more sense to be able to write
assembler statements in which the location of the variable is inserted by
the compiler.

Most of the C compilers I know do not do this; it is at the least annoying
not to be able to write such things as

	asm("	addl	x,y,z");
	asm("	addwc	u,v,w");

and have the compiler include those location for the variables.  (What I do
is to first compile as above and then edit, but it does not always work.)
We also should get rid of those quotes in the process; since asm is a reserved
operator, and its structure requires that what follows starts with ("
and ends with "), while the parentheses may be useful as separators, the
quotes are totally unnecessary (and have been known to cause errors).
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet