Re: Microarch Club

On Thu, 28 Mar 2024 09:31:11 +0100
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes: 

BGB wrote:
 

On 3/26/2024 5:27 PM, Michael S wrote: 

>
>
For slightly less then 20 years ARM managed OK without integer
divide. Then in 2004 they added integer divide instruction in
ARMv7 (including ARMv7-M variant intended for small
microcontroller cores like Cortex-M3) and for the following 20
years instead of merely OK they are doing great :-)
 

 

OK. 

>
The point is they are doing better now after adding IDIV and FDIV.
 

I think both modern ARM and AMD Zen went over to "actually fast"
integer divide. 

 

I think for a long time, the de-facto integer divide was ~ 36-40
cycles for 32-bit, and 68-72 cycles for 64-bit. This is also
on-par with what I can get from a shift-add unit. 

>
While those numbers are acceptable for shift-subtract division
(including SRT variants).
>
What I don't get is the reluctance for using the FP multiplier as
a fast divisor (IBM 360/91). AMD Opteron used this means to
achieve 17-cycle FDIS and 22-cycle SQRT in 1998. Why should IDIV
not be under 20-cycles ?? and with special casing of leading 1s
and 0s average around 10-cycles ??? 

 
Empirically, the ARM CortexM7 udiv instruction requires 3+[s/2]
cycles (where s is the number of significant digits in the
quotient).
 
https://www.quinapalus.com/cm7cycles.html 

 
That looks a lot like an SRT divisor with early out?
 
Having variable timing DIV means that any crypto operating (including
hashes?) where you use modulo operations, said modulus _must_ be a
known constant, otherwise information about will leak from the
timings, right?

Are you aware of any professional crypto algorithm, including hashes,
that uses modulo operations by modulo that is neither power-of-two nor
at least 192-bit wide?