Newsgroups: comp.arch
Path: utzoo!utgpu!watserv1!watdragon!rose!ccplumb
From: ccplumb@rose.uwaterloo.ca (Colin Plumb)
Subject: Re: bizarre instructions
Message-ID: <1991Feb22.045822.18324@watdragon.waterloo.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
References: <9102210042.AA12291@ucbvax.Berkeley.EDU> <6503@mentor.cc.purdue.edu> <45405@nigel.ee.udel.edu>
Date: Fri, 22 Feb 1991 04:58:22 GMT
Lines: 51

new@ee.udel.edu (Darren New) wrote:
>How about this?  A language in which it is possible to write functions
>in assembler and have them inlined automatically, and to have the
>compiler smart enough to do dataflow analysis on the resultant code and
>such.  Possibly some syntax close to what PCC uses could be used inside
>such functions.  I would imagine that GCC is close to capable of doing
>this if it isn't already. The minor problem of efficient multi-variable
>returns might need to be worked out.

GCC is already.  I saw a 68881 floating-point include file for gcc that
was nothing more than

static inline const double sin(register double x)
{
	register double ans;
	asm("fsin %1,%0" : "=f" (ans) : "f" (x));
	return ans;
}

The syntax is a bit cryptic to express everything you can tell the
optimizer about, but basically, the first string is a pattern, and the
colon-separated parts are output and input operands (you can add
another section for clobbered registers).  "=f" means it needs an "f"
type operand (which the machine description uses for floating point
args) and it's assigned to.  "f" means it's not assigned to.  Gcc will
merge your code in with the caller, hoist sin() out of loops it's invariant
in (const in the function type says you can do that with this function,
although once it's inlined, gcc can see that for itself), and generally
behave as if sin() was an intrinsic rather than a library call.

You can also express the idea that a given input is not read until after
the outputs are written, that an input and output have to be in the same
place, and other things.

>Then, the only stumbling block would be the flexible syntax for
>procedure calls, which could be addressed with a preprocessor rather
>than an entire language.
>
>Am I missing something here, or is this problem really as easy to
>solve as it seems?             -- Darren

Well, the syntax is clumsy for really large blocks, but it works well for
dropping, for eaxmple, an atomic test-and-set or compare-and-swap into
some C code.

I believe the reason it isn't more commonly done is that few compilers
have the strong separation gcc does between the compiler and the machine
description.  So you can't easily add a description of an instruction at
run time and have the optimizer work with it smoothly.
-- 
	-Colin


Brought to you by Super Global Mega Corp .com