[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFYn=yA+QBS=aezs4LLrJ2uqxmAL73YzfU4C5ex-GyN0vSovKg@mail.gmail.com>
Date: Sun, 21 Jul 2013 23:32:41 -0400
From: Yaniv Sapir <yaniv@...pteva.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
Hi Katja,
Yes, e-gcc supports extended inline assembly w/o a problem. Here's the
reference:
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm
int var0, var1, var2;
__asm__ __volatile__ ("ldr %0, [%1, %2]" : "=r" (var0) : "r" (var1), "r"
(var2));
__asm__ __volatile__ ("ldr %[outvar], [%[base], %[offset]]" : [outvar] "*=*r"
(var0) : [base] "r" (var1), [offset] "r" (var2));
__asm__ __volatile__ ("testset %[key], [%[base], %[offset]]" : [key] "*+*r"
(var0) : [base] "r" (var1), [offset] "r" (var2));
Yaniv.
On Sun, Jul 21, 2013 at 9:08 PM, Katja Malvoni <kmalvoni@...il.com> wrote:
> Hi Yaniv,
>
> Does e-gcc support specifying input, output and modified registers as gcc
> inline assembly does? I couldn't make it work using the following syntax:
>
> __asm__(
> ...instructions...
> : output registers
> : input registers
> : clobbered registers
> );
>
> First error I get is for colon. Is there a way to reference C variable
> from inline assembly?
> If not, how can I safely implement part of C code in assembly? (more
> precisely BF_ROUND)
> I tried to do that using macro but the problem is that assembly code
> around macro changes and my implementation is not reliable because e-gcc
> generated code sometimes uses different registers when other C code is
> changed.
> How are function arguments passed? First one is stored in r0, second in
> r1, third in r2, forth in r3 (counting from left to right) and the rest of
> them are placed on stack?
>
> Thank you
>
> Katja
>
>
>
>
> On Sun, Jul 21, 2013 at 10:04 PM, Solar Designer <solar@...nwall.com>wrote:
>
>> On Sun, Jul 21, 2013 at 07:21:27PM +0200, Katja Malvoni wrote:
>> > In internal.ldf all code is in local memory, in fast.ldf user code and
>> > stack are placed in local memory while standard libraries are in
>> external
>> > SRAM.
>>
>> I think you mean external DRAM.
>>
>> OK, this explains it. I did not realize that memcpy() was not in local
>> memory.
>>
>> > > So I don't buy it when you say that BF_ROUND and BF_encrypt are
>> already
>> > > optimal.
>> [...]
>>
>> > I agree now, I was looking at whole thing from completely wrong
>> > perspective. I didn't see the fact that using IADD doesn't mean it will
>> be
>> > faster than ADD but it means IALU will be free for other instructions.
>>
>> I took another look at sections "7.9 Pipeline Description" and "7.10
>> Dual-Issue Scheduling Rules" in epiphany_arch_reference_3.12.12.18.pdf,
>> and from those it appears that we'll need to interleave 2+ instances of
>> bcrypt if we're to use IADD and possibly IMADD efficiently, because FPU
>> instructions take 3 cycles more to complete than IALU ones do. (This is
>> extra latency only; it does not mean that these instructions are any
>> slower in terms of throughput - it's 1 instruction per cycle in terms
>> of throughput for IALU and FPU, so 2 per cycle total.)
>>
>> When we don't use the FPU at all, we're only capable of issuing one
>> instruction per cycle. So using IADD and possibly IMADD is our only
>> hope at dual-issue.
>>
>> Alexander
>>
>
>
>
> --
> Katja
>
--
===========================================================
Yaniv Sapir
Adapteva Inc.
1666 Massachusetts Ave, Suite 14
Lexington, MA 02420
Phone: (781)-328-0513 (x104)
Email: yaniv@...pteva.com
Web: www.adapteva.com
============================================================
CONFIDENTIALITY NOTICE: This e-mail may contain information
that is confidential and proprietary to Adapteva, and Adapteva hereby
designates the information in this e-mail as confidential. The information
is
intended only for the use of the individual or entity named above. If you
are
not the intended recipient, you are hereby notified that any disclosure,
copying,
distribution or use of any of the information contained in this
transmission is
strictly prohibited and that you should immediately destroy this e-mail and
its
contents and notify Adapteva.
==============================================================
Content of type "text/html" skipped
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.
