[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Oct 2013 08:18:04 -0400
From: Yaniv Sapir <yaniv@...pteva.com>
To: john-dev <john-dev@...ts.openwall.com>
Subject: Re: bcrypt-parallella on 64-core (was: Katja's weekly
report #13)
IIRC, I named those registers based on Katja's printout for core states.
Some register values seemed odd so I specifically asked about them.
However, the limitation is certainly relevant to all registers.
I will consult Andreas and make up an errata list.
On Wed, Oct 30, 2013 at 8:05 AM, Solar Designer <solar@...nwall.com> wrote:
> Yaniv, Katja -
>
> On Wed, Oct 30, 2013 at 07:51:38AM -0400, Yaniv Sapir wrote:
> > The problem is not with certain registers, but with certain cores. Cores
> on
> > the 2nd row should not *load *or *fetch *from external memory. DMA reads
> > are OK.
>
> Oh. I was referring to:
>
> http://www.openwall.com/lists/john-dev/2013/09/18/3
>
> "(A very long shot:) In the stuck cores, do you have external loads into
> registers R53, R0, R2, R38, respectively?"
>
> so it sounded like the problem had something to do with certain
> registers (as well as certain cores).
>
> Further in that thread, Katja confirmed that "there exists external load
> intto r38 in compiler generated code":
>
> http://www.openwall.com/lists/john-dev/2013/09/19/6
>
> and asked "Is it possible to force e-gcc not to use r38 and r53?":
>
> http://www.openwall.com/lists/john-dev/2013/10/01/8
>
> Maybe this can in fact be done by placing some local variables into
> those problematic registers (using the syntax I just posted about),
> and either only using those variables for other than external loads or
> keeping them unused. Like I said, I am unsure if this syntax prevents
> gcc from making other use of the same registers, though.
>
> Yaniv, it'd be helpful if you post a full set of relevant Epiphany-IV
> errata (specifically for E64G401?) in one message.
>
> For example, I am confused whether the problem with certain registers
> occurs only on certain cores (that is, when both the core and the
> register number are problematic) or whether it's independent (that is,
> a problem occurs when either register or core number is problematic).
>
> Thanks,
>
> Alexander
>
--
===========================================================
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.
