Path: utzoo!utgpu!bnr-vpa!bnr-fos!bnr-public!schow
From: schow@bnr-public.uucp (Stanley Chow)
Newsgroups: comp.arch
Subject: Re: Complex Instructions
Summary: C is not the whole game
Message-ID: <426@bnr-fos.UUCP>
Date: 21 Apr 89 02:04:48 GMT
References: <57252@yale-celray.yale.UUCP> <4101@tolerant.UUCP> <134@dg.dg.com>
Sender: news@bnr-fos.UUCP
Reply-To: schow@bnr-public.UUCP (Stanley Chow)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 52

In article <134@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes:
>
>As a result of this difficulty, architects begain to build in
>instructions to handle data structures more directly.  However,
>few of these instructions can be compiled since the C compilers
						    ^^^^
>have difficulty decyphering the code well enough to know when
>to use the "insert into circular queue" instruction as opposed to
>smaller operations to manipulate pointers.  Also, few programmers
>are sufficiently versed in the underlying hardware to generate
>compatible data structures which could allow a very smart compiler
>to generate the instructions in the first place.
>

There are many other compilers that can take advantage of complex
intructions. Actualy, even in C, it is relatively easy to set up
include files that will declare the right data types and inline
procedures [assuming your compiler let's you.]

Throwing out architectural features just because C can't use it? 
There are other languages.  How about throwing out C instead? :-)

Also, 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.

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.


>I personally prefer the way DG/UX handles things.  (I'm biased, I 
>work for DG.)  Each virtual processor contains a value called "atomic
>operation count" which can be raised or lowered (somewhat like parenthesis
>can be nested).  Whenever the AOC is > 0, the processor cannot be suspended
>for anything but a simple interrupt service.  This guarantees that atomic
>operations can complete without interference.  If more stringent control
>is required, then some form of event counter solution is used.

I like this design. Sound like it is implemented by the kernal for virtual
processors. How do you handle the case of kernal not wanting to be 
interrupted?



Stanley Chow   ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public


My opinions are mine alone. Since there has been no interest in others
being represented by them, I am lowering the representation fee.