Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!purdue!haven!vrdxhq!daitc!daitc.daitc.mil
From: jkrueger@daitc.daitc.mil (Jonathan Krueger)
Newsgroups: comp.arch
Subject: Re: Complex Instructions
Message-ID: <504@daitc.daitc.mil>
Date: 2 May 89 18:07:36 GMT
References: <57252@yale-celray.yale.UUCP> <4101@tolerant.UUCP> <134@dg.dg.com> <426@bnr-fos.UUCP>
Sender: jkrueger@daitc.daitc.mil
Reply-To: jkrueger@daitc.daitc.mil (Jonathan Krueger)
Organization: DTIC Special Projects Office (DTIC-SPO), Alexandria VA
Lines: 26

In article <426@bnr-fos.UUCP>, schow@bnr-public (Stanley Chow) writes:
>it is not necessary for all programmers to know enough to use
>the specail instructions. Some guru can set it up and everyone can
>then use the pre-built modules. Depending on how you set everything
>up, the compiler does not have to be smart at all.

Of course, but you lose the performance advantage if the modules get
called frequently and require significant setup (e.g. can't maintain
state for multiple callers or sequences) with respect to work
performed.  Or to put it another way, That Way Lies Threaded Code.
However, this isn't an argument for Better Living Through Inlining,
rather an appeal for analysis and measurement of the tradeoffs.

>For example, we have a system with really wild instructions that gets
>generated even though the user don't know what they are and the
>compiler does only peephole optimization. As is turns out, having
>atomic operations for free is really nice.

Sounds like you've managed to let your users express what they want in
terms familiar to them but also understandable to the language
translator, following which optimization to particular hardware can be
done in a reasonable way.  By any chance, would this be done by way of
a function library?

-- Jon
--