[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 Jul 2013 03:08:37 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
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
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.
