[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130903115412.GB19261@openwall.com>
Date: Tue, 3 Sep 2013 15:54:12 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Rafael's weekly report #12
Rafael,
On Tue, Sep 03, 2013 at 12:57:56AM +0100, Rafael Waldo Delgado Doblas wrote:
> Accomplishments:
> 1. Debuged epiphany-scrypt and driver-epiphany.
> 2. Replaced memcpy, it improve a little bit the performance.
> 3. Started with asm inline codification.
That's too little progress for a week. It feels like you're simply not
allocating enough time to the project - like, catching up during the one
day before each weekly report, or similar. For example, when did you
have the asm experiment results (that you included below) ready? If you
had them ready before the weekly report was due on Monday, then why
didn't you post them right away? You should have!
> Well I started with inline asm. But the results weren?t better than C. This
> is because the C compiler optimizes the Bout vector access storing it in
> the general registers and after calls to R macro:
>
> 7b0: 879f e10a add r60,r1,r23
> 7b4: b32f fc06 lsr r61,r60,0x19
> 7b8: 90ff fc06 lsl r60,r60,0x7
> 7bc: 967f ff8a orr r60,r61,r60
> 7c0: 4a0f 6f8a eor r26,r26,r60
>
> Howerver when I define the R function with inline asm:
> __asm__("LSR r60, %1, %3\n\tIMADD r60, %1, %4\n\t EOR %0, %1, r60" \
> : "=r"(b)\
> : "r"(a), "r"(b), "n"(c), "r"(d) \
> : "memory", "%r60" \
> );
Indeed, you've specified that you're modifying "memory", which tells the
compiler that whatever it had cached in registers might no longer match
the actual variable values after this piece of inline asm. I see no
reason for you to specify "memory" here - perhaps just drop it and see
if that helps?
> BTW fmadd/imadd has cannot work with immediate values then we will need to
> add extra 4 movs in order to store the multiplication constants in
> registers.
Yes. That's OK. Those extra MOVs should be out of the loop.
> I will write a new ASM file with the salsa20_8 implementation using the C
> optimized version as base.
Feel free to try that. Please use a .S file (with cpp macros), like
Katja ended up doing.
Since this project is progressing way slower than it should, can you
please start posting daily reports until the end of GSoC (in addition to
the weekly reports with the accomplishments and priorities)? It feels
like you're working on the project for like 1 day per week now, and we
need to change that.
The daily reports don't need to be of a formal structure - just
something showing that you make progress each and every day, and what
kind of progress - as well as what issues you're running into.
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
