On 2009-10-29, Timothy Normand Miller wrote:
> On Wed, Oct 28, 2009 at 4:42 AM, Petter Urkedal <[email protected]> wrote:
> > On 2009-10-27, Timothy Normand Miller wrote:
> >> On Mon, Oct 26, 2009 at 5:45 PM, Petter Urkedal <[email protected]> wrote:
> >> >> > 4. I like the idea of adding minimum and maximum functions in the
> >> >> > instruction set; if we need them, that is. They should not require
> >> >> > much
> >> >> > logic. But in this case, note that there is a difference between
> >> >> > signed
> >> >> > and unsigned. Do we want both? On the other hand it only takes 2 to
> >> >> > 3
> >> >> > cycles to compute any of these if my idea of the instruction set is
> >> >> > correct.
> >> >>
> >> > On 2009-10-26, Timothy Normand Miller wrote:
> >> >> We CAN implement this with branches, which are a bit cheaper because
> >> >> we don't have a delay slot. We'll softof automatically have both
> >> >> signed and unsigned variants of branch instructions in some cases.
> >> >
> >> > I'm hoping we can support a fairly complete set of branch conditions.
> >> > If we have space in the instruction world, conditional write-back would
> >> > reduce min and max to two instructions, that seems questionable at the
> >> > moment. Still, I'm not against min/max primitive if they're common.
> >>
> >> We can either have a write-back flag, or we can make r0 the bit bucket.
> >
> > I was really thinking of conditioned instructions, not just a fixed
> > throw-away of the result. E.g. computation of min as
> >
> > ;; Computation of r1 := min {r1, r2}
> > sub r1, r2, r0
> > move r2, r1 if_neg r0
> >
> > Though without flags, the conditional modifier is only applicable to
> > unary instructions, which severely limits its usability.
>
> I just don't see where you're going to put the bits for that.
Well, I have place for those bits if I only support conditions on unary
instructions, leaving 8 bits. But then this "severely limits its
usability". Feature buried.
> One option, actually, is to make the regfile banked or have a sliding
> window. Now, we can use fewer bits for register numbers, and we have
> room for other stuff. We could do this by splitting DECODE into
> DECODE and REG, where DECODE does the offset.
>
> I'm not particularly fond of sliding window register files.
There may be an argument for it, considering it as fixed stack frames,
but I'm afraid it would be too inflexible. At least one should split
the regs into a fixed part and a sliding part to account for globals.
It doesn't appeal to me either, so I'd rather shelf it for desperate
times.
> > Here is another thought. We don't need write-back for branches. If 8
> > bits suffice for short jumps, that leaves room for two operands. Thus,
> > we could make branch instructions which share logic with the arithmetic
> > instructions, up to the point where the write-back or jump happens.
> > However, but the implied functionality seems redundant, and this
> > approach may leave us no bits for selecting the condition on which to
> > branch. So instead they could be based solely on subtraction:
> >
> > ifeq ri, rj, target
> > ifneq ri, rj, target
> > ifule ri, rj, target ; if (uint)ri ≤ (uint)rj then jump_to target
> > ifult ri, rj, target
> > ifsle ri, rj, target
> > ifslt ri, rj, target
> >
> > The latter four instructions will coincide with min and max logic. The
> > idea here is to test and act on the carry and overflow flags on the same
> > cycle they are generated, so that we don't need to save them. If 8 bit
> > target is too narrow, the compiler can generate
>
> 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.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
