Date: Sun, 21 Jul 2013 23:35:39 -0400 From: Yaniv Sapir <yaniv@...pteva.com> To: john-dev@...ts.openwall.com Subject: Re: Parallella: bcrypt Function arguments are passed in the first four GP registers, following arguments are passed on the stack. You can compile a simple function with 5 or 6 arguments, make the output the sum of all six and see how the compiler refers to each of the arguments and the returned value (in R0). 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_18.104.22.168.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.