On Thu, Oct 29, 2009 at 4:52 PM, Petter Urkedal <[email protected]> wrote:
>> One reason I like separating the compare instruction from the branch
>> instruction is that we now get to reuse an existing instruction (sub,
>> subf), and we get to choose the one correct for the datatype.
>
> In that case, my original though was to merely make the branch
> instructions variant of the arithmetic instructions.  We'd steal a bit
> from load and store and encode them as
>
>    000.. load
>    001.. store
>    00... arith-and-write-back
>    01... arith-and-branch-if-zero
>    10... arith-and-branch-if-negative
>    11... long-jump
>
> The branches are 8 bit relative, where the 8 bits coincide with the
> register number for write-back in 00... instructions.  If we have bits
> left, we can add more tests.
>
> This is basically a contraction of an arithmetic and branch instruction,
> which may pay off if branches are within ±127 slots in the common case.
>
>> In the case of multi-word integers, wouldn't we mostly be using carry,
>> not overflow?
>
> Yes.

Ok, I like the idea.  We need to start listing the critical
instructions (they're in the doc, mostly), and see how they're all
going to fit.

Also, Andre and I are failing to agree in general on how branches
should be handled.  I prefer the MIPS way, which involves an
arithmetic instruction followed by a branch instruction that examines
the result.  The reason I like that is that I don't like condition
codes.

On the other hand, Andre and Kenneth are doing most of the work here,
and we need to defer to them.  Andre prefers condition codes.  One set
(CNVZ) for each thread, which are produced by most (but not all)
instructions.  This is a more traditional way of doing things.  The
thing that bugs me about this is that you can't have multiple
out-standing conditions.

However, I have failed to make a solid argument in favor of having
multiple out-standing conditions.  I have my preference, and he has
his, which means he wins.  :)

Can you (or anyone else) think of any really compelling argument in
favor of having multiple out-standing conditions?

One major advantage of doing it the MIPS way is that they didn't have
extra dependencies between instructions to keep track of.  We don't
have that problem.  Context switches are also slightly simpler.  We
don't have that issue either.  None of the ORIGINAL arguments in favor
of the MIPS way hold up.


-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to