Path: utzoo!attcan!uunet!ssbell!dsndata!wayne
From: wayne@dsndata.uucp (Wayne Schlitt)
Newsgroups: comp.arch
Subject: Re: End-of-buffer interrupt instruction
Message-ID: <WAYNE.90Sep17125041@dsndata.uucp>
Date: 17 Sep 90 16:50:41 GMT
References: <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <2123@key.COM>
	<2128@key.COM> <2567@l.cc.purdue.edu>
Sender: wayne@dsndata.UUCP
Organization: Design Data
Lines: 49
In-reply-to: cik@l.cc.purdue.edu's message of 17 Sep 90 12:52:14 GMT

In article <2567@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> Let me clarify the situation.  There are natural situations arising in 
> Monte Carlo where one cannot predict when a buffer will empty.  Steps
> can be taken to make it rare.  Therefore, the "natural" way to want to
> handle this is to have an interrupt, or exception if you prefer, when
> this does happen.  [ ... ] 
> 
> The advantage of an interrupt procedure over a test each time is that
> the interrupt is rare, and does not have the costs of the test when it
> is not invoked.  It is likely to lengthen the instruction, however.  On
> the other hand, an interrupt certainly has much higher costs than the
> test when it does cut in.


the more i think about it, the less i see any value of this type of
instruction.  IFF your processor has a deep pipeline and/or it doesnt
stall on loads from memory AND your buffer isnt in cache, then your
compare is going to be totally hidden by the delay of loading from
memory.  let's look at the code...


you want something like this:

top_of_loop:
        add     R1,R0                   # do something with R0        
        loadbuf R0,buffer,endofbuf      # fetch something from the buffer
                                        # check to make sure it isnt past
                                        # endofbuf and increment buffer to
                                        # to the next item
        bra     top_of_loop             # do some more processing.


instead, what you are getting is:

top_of_loop:
        add     R1,R0                   # do something with R0
        load    R0,(buffer)             # fetch something from the buffer
        cmp     R0,endofbuf             # see if we are at the end of buf
        ble     top_of_loop             # if not, go process it
        inc     buffer                  # ye, old, delay slot of the branch

since R0 isnt going to be ready to use for several instructions after
the load, your code is simply going to stall on the add at the top of
the loop.  the code you are getting is going to be doing the compare
instead of stalling.  it dont see what the difference is.  your loop
isnt going to run any faster...


-wayne