We don't have SH hardware, and the MIPS code is already more improved. Sorry we
took so long to get to this.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2337
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
Vincent,
Now back to As I don't have access to little-endian MIPS, I'd like to
reserve for option to ask you test it at some later point. I've just
committed aes-mips.pl module, see
http://cvs.openssl.org/chngview?cn=19941, and wonder if you could test
it on your system? A lot of thanks in
Now back to As I don't have access to little-endian MIPS, I'd like to
reserve for option to ask you test it at some later point. I've just
committed aes-mips.pl module, see
http://cvs.openssl.org/chngview?cn=19941, and wonder if you could test
it on your system?
Failed to mention that
Vincent,
In fact, there was another bug in little endian mode: a typo with tmp2.
Please find the patch correcting them.
Thanks! http://cvs.openssl.org/chngview?cn=19940 is committed.
Now back to As I don't have access to little-endian MIPS, I'd like to
reserve for option to ask you test it at
- for completeness, I made a quick PICification of the aes-mips32. MIPS
indeed seem much more easy on PIC code.
For [future] reference. PIC-ification on MIPS involves setting up $gp
(achieved with .cpload directive under o32) and addressing relative to
its value (achieved with .option pic2
- the MIPS plateform I use is indeed little endian.
I will take a look to your question tomorrow.
I may not have seen the bug since I didn't made test with sha512 up to
now (only for bn_xxx/aes/sha1/sha256).
The below remark is about sha256 code! For now sha512-mips.pl module can
generate
Hi,
In fact, there was another bug in little endian mode: a typo with tmp2.
Please find the patch correcting them.
Vincent
On Tue, Oct 19, 2010 at 10:24 AM, Andy Polyakov ap...@openssl.org wrote:
- the MIPS plateform I use is indeed little endian.
I will take a look to your question
Vincent,
As I don't have access to little-endian MIPS,
In other words my understanding is that *your* MIPS platform is
little-endian, isn't it? I noticed something that has to be a bug in
sha512-mips.pl, which would fail sha256 test on little-endian MIPS32
platform. Specifically $MSB assignment
3. Position independence is still problem.
- In SH4 asm, the MOVA is hidden behind a normal mov.l without a base
register, so in fact, it is used very often.
Can't confirm this. Well, I can see now that it extensively uses 'mov.l
@(disp,PC),Rn' for loading constants,
There will be more comments later.
BODY_00_xx in SHA1 module. There is branch covering for unaligned input.
I'd suggest movua.l, but then I noticed that it's missing in manual
you've mentioned. Is it recently introduced instruction or is it
erroneously omitted from manual? On a side note I
2/ for MIPS, I just left the AES and BN :
- AES currently supporting mips32 gcc only, since I cannot test it on
any other systems.
You could adapt it to your other mips machines, if you want to.
- BN for mips32 since I find this framework much cleaner and more
readable than the generated
Hi,
There will be more comments later.
- for SHA1(x2) /SHA256(+40%), not such to say. The SHA256 gain is
limited due to the low register count of the SH4
It was not my intention to make you implement SHA256. But since you've
chosen to do it here it goes.
1. The file should have been called
Hi,
Thank you for your quick feedback, I added some comments,
Vincent
On Thu, Oct 14, 2010 at 11:53 AM, Andy Polyakov ap...@openssl.org wrote:
Hi,
There will be more comments later.
- for SHA1(x2) /SHA256(+40%), not such to say. The SHA256 gain is
limited due to the low register count of
2. Why do you use tables of small constants? There is 'mov #imm,Rn'
instruction, where #imm is 8-bit signed value. Works for all [Ss]igma
constants. As for mask_ff. There is extu.b that does 0xff...
This is very important for the sh4 serie 200 pipeline: there is only one
ALU
On Thu, Oct 14, 2010 at 4:37 PM, Andy Polyakov ap...@openssl.org wrote:
2. Why do you use tables of small constants? There is 'mov #imm,Rn'
instruction, where #imm is 8-bit signed value. Works for all [Ss]igma
constants. As for mask_ff. There is extu.b that does 0xff...
This
Ok I find it:
http://documentation.renesas.com/eng/products/mpumcu/rej09b0318_sh_4sm.pdf
page 172
On Thu, Oct 14, 2010 at 7:43 PM, Vincent Labie vincent.labi...@gmail.comwrote:
On Thu, Oct 14, 2010 at 4:37 PM, Andy Polyakov ap...@openssl.org wrote:
2. Why do you use tables of small
3. Position independence is still problem.
= I know, nevertheless, if you compile code on SH4 with gcc with
-PIC,
then the same apply, so currently, I don't see the point to make real
PIC code on this CPU.
Are you afraid of doing better job than compiler?
Furthermore,
something needs to be done about the way you pull addresses to Te/Td
tables. Normally I'd settle for placing Te in .text segment and then
bal .+8
nop
$PTR_ADD $x,$31,Te-.
Unfortunately there is toolchain that does not allow placing data in
.text
... suggested mips32.S
miserably fails to compile on my [IRIX] system. ...
I suppose I'll have to see if I can manage to compile mips32.S...
I figured I might as well adapt my mips3.s from 1999 instead. It worked
by mechanical replacement of 64-bit instructions for corresponding
32-bit ones.
Hi,
--- As you suggested, I made some benchs to compare the mips-mont and
mips32.S asm functions. It appears that indeed mips-mont.pl func is
better for small 512 rsa key signing, but generic C montgomery with
optimized bn_xxx_word file is quite better from 1024 verifing. From
2048 on it is
- this code is not cache attack resistant,
but the performance penality would be just too high.
Too high is non-objective measure:-) Anyway, compressed tables I was
referring to don't necessarily refer to minimal of 256B. I was rather
referring to 1KB or 2KB tables. I mean what is relation
21 matches
Mail list logo
