Portable "asm" (Was: The D Programming Language)
Herman Rubin
cik at l.cc.purdue.edu
Mon Feb 22 22:56:20 AEST 1988
In article <4257 at june.cs.washington.edu>, pardo at june.cs.washington.edu (David Keppel) writes:
> In article <915 at PT.CS.CMU.EDU> edw at 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 at l.cc.purdue.edu (ARPA or UUCP) or hrubin at purccvm.bitnet
More information about the Comp.lang.c
mailing list