[libre-riscv-dev] [Bug 189] Create partitioned right shift using the existing partitioned left shift

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=189

Jacob Lifshay <programmerjake at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |programmerjake at gmail.com

--- Comment #9 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #8)
> (In reply to Michael Nolan from comment #7)
> 
> > Rol ra, rb, rc getting translated to
> > 
> > shl tmp1, rb, rc
> > shr tmp2, rb, (32-rc)
> > or  ra, tmp1, tmp2
> > 
> > should be constant time with respect to the data being manipulated. 
> 
> so there are a couple ways to do the micro-coding, one of them being to
> have "spare" inputs (extra Function Units) to the pipelines, which
> the normal instruction issue engine does not have access to.
> 
> the output from the shl (tmp1) goes into an *extra* FU operand 1 on an OR
> pipe.
> the output tmp2 goes into the operand2 of the OR pipeline's extra FU.
> 
> finally the output from the OR goes into ra, in the *normal* result system.
> 
> it's basically hard-coded micro-code, rather than "programmable" micro-code.

sounds good!

> 
> 
> > The
> > actual timing probably depends on what else is in the pipe, but that's true
> > of other instructions as well.
> 
> please, nobody mention spectre or other timing-related attacks.  sigh.

I was referring to data-dependent timing, which is quite easy to get right in
this case (don't do things like translating to a variable number of 1-bit
rotations).

With regards to spectre, we should still try to mitigate it in cases where it's
relatively easy and doesn't have a major performance loss (not this specific
case of scheduling bitwise-or instructions).

-- 
You are receiving this mail because:
You are on the CC list for the bug.