Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!snorkelwacker.mit.edu!shelby!decwrl!sdd.hp.com!wuarchive!udel!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.arch
Subject: Re: bizarre instructions
Message-ID: <7063:Mar202:29:0091@kramden.acf.nyu.edu>
Date: 2 Mar 91 02:29:00 GMT
References: <10278@dog.ee.lbl.gov> <3025@charon.cwi.nl> <PCG.91Feb28182206@odin.cs.aber.ac.uk>
Organization: IR
Lines: 30

In article <PCG.91Feb28182206@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
> What you want is not a technical solution, it is legislation. "There
> ought to be a law..."; in your case it is one that makes compiler
> writers provide your favourite primitives on all the platforms you want
> to use.

I don't think this is practical. I have my favorites, and you have your
favorites, and when you take the overall favorites of programmers around
the world you have way too many operations for any one language to
support.

To put it differently, there will always be *some* primitive that a chip
designer implements or that a programmer wants, and that isn't in the
language. If the chip designer provides X and the programmer wants X but
the language doesn't understand X, the programmer is screwed.

What I do think is practical is having each compiler writer at least
provide a portable idiom for each instruction on his machine. (Portable
doesn't mean everyone will recognize the same idiom the same way; it
just means that the idiom is written portably in the language.) This is
much more manageable, and it ensures that the programmer will never hit
a wall between what the compiler lets him do and what he can accomplish
in assembly.

Note that some compilers go halfway, and provide unportable idioms
(e.g., directives). I find these to be no better than assembly language,
because I can't take a program with directives and use it without change
on another system.

---Dan