Newsgroups: comp.arch
Path: utzoo!utgpu!watserv1!watdragon!rose!ccplumb
From: ccplumb@rose.uwaterloo.ca (Colin Plumb)
Subject: Re: bizarre instructions
Message-ID: <1991Feb26.213113.26499@watdragon.waterloo.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
References: <9102220245.AA14853@ucbvax.Berkeley.EDU> <10278@dog.ee.lbl.gov> <6870@mentor.cc.purdue.edu> <1991Feb26.174559.9417@linus.mitre.org>
Date: Tue, 26 Feb 1991 21:31:13 GMT
Lines: 61

bs@linus.mitre.org (Robert D. Silverman) wrote:
>:> In article <1991Feb25.203629.5059@linus.mitre.org> bs@faron.mitre.org
>:> (Robert D. Silverman) writes:
>:>> Ah yes. A universal solution. Machine dependent. Ugly syntax. Only
>:>> works with one compiler.

I submit it's better than most, and allows mostly what you'd like.
Also, gcc is very widely available, and might inspire others.

>Actually I would settle for the following:::
>
>I am more than willing to write the assembler code for an operation
>     ----
>we will call FOO. FOO takes 3 arguments and returns 2 more.
>
>I would then like to see the following in a HLL:
>
>	asm_routine(FOO(a,b,c,d,e))
>
>The compiler will then fetch my assembler routine, and RESOLVE any
>register/stack/addressing conflicts that might arise because the
>assembler routine uses the same registers/addresses etc. that are
>produced by the calling routine.
>
>FOO would be written as an ordinary subroutine; it would assume that
>the arguments to it had been placed on the stack the same as any other
>subroutine call.
>
>The compiler will straighten out any conflicts [renaming registers
>within the assembler routine as needed etc.] and then in-line the
>assembler routine.

Som the compiler has to be able to parse either object files or
assembler source (I'm not sure which you mean), follow the data flow
(with possible aliasing) in the procedure-calling convention, know the
operand restrictions (does it need to be in registers or can it accept
a memory operand?) and implicit operands (MQ on the MIPS chip,
r0/r1/r2/...  for VAX movec instructions, etc.) of every instruction,
and in-line it?  I think this is awfully impractical.

The gcc solution, while syntactically messier, tells the compiler the
things it needs to know for optimisation purposes in a form it can
easily understand, and just supplies a string pattern to emit to the
assembler, so the compiler doesn't have to know how to parse assembler
input.

It can also handle new instructions the compiler has not yet been extended
to handle when a 32732/68050/80586/R5000/whatever comes out.

I respectfully suggest that you wouldn't like the results of what you
suggest either, like the people in Jon Bentley's story who wanted to
type a list of ~200 districts into the computer and get a random sample
(~5) out.  He suggested perhaps having the computer emit a few random
numbers and looking them up on the paper list would be a lot easier
than typing in the paper list.

I also suggest that you don't want it embedded in the source that the
code is an assembler routine, so you can supply a high level version
if it becomes necessary.
-- 
	-Colin


Brought to you by Super Global Mega Corp .com