Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!husc6!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.arch
Subject: Open coding (was Re: Complex Instructions)
Message-ID: <39670@think.UUCP>
Date: 24 Apr 89 15:47:42 GMT
References: <57252@yale-celray.yale.UUCP> <4101@tolerant.UUCP> <134@dg.dg.com> <39609@think.UUCP> <1257@l.cc.purdue.edu>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 25

In article <1257@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>It is not true that all languages provide procedures for open coding.
		     ^^^ I said "most", not "all".
>Most provide some procedures for attempting to open-code, but most
>implementations I have seen discourage this.  

Are you talking about LANGUAGES or IMPLEMENTATIONS?  What languages
don't permit built-in operations to be open-coded?  What does it mean
for an implementation to "discourage this"?  Either a compiler
open-codes a particular operation or it doesn't.  Maybe we're talking
about different things (it sounds like you're talking about
user-defined inline functions).

Remember, my posting also mentioned hiding these things away in
subroutine libraries.  If the operations are sufficiently expensive
(such as multiple-precision integer arithmetic), the expense of a
subroutine call should not be a problem, and you probably wouldn't
want the routines expanded inline all over the place, either.


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar