Re: [f-cpu] RC5, F-CPU and srotl

[Yann Guidon <whygee@f-cpu.org>]

hi !

Michael Riepe wrote:
> On Fri, Apr 12, 2002 at 07:07:37AM +0200, Yann Guidon wrote:
> [...]
> > > Crypto stuff may be "cool",
> > if you know the CCC guys, you will understand what i mean ;-)
> I know some of them. But I don't think what they do is "cool", sorry.
i don't say that everybody at CCC is "cool". I meant that some of them
are really insterested by F-CPU because they see that they can program
efficient "DNET" clusters and have all the garanties of the absence of
backdoors or flaws.

> > they are the one who introduced to this field and if F-CPU holds its promises,
> > they will continue to help us.
> You mean, invite us to this year's CCC?
xC3 is a big party where we can meet and evaluate each others
and we currently are not advanced enough. However, if f-cpu becomes
a reality, they can help promote the chips. They won't drop their
VAX or ACORN but will make a place for a computer they can hack
deeper than anything they know. that's something "cool" in their eyes,
i think.

> > >  Besides that, many crypto
> > > algorithms can be done better (and faster) in dedicated hardware.
> > yup but they often do only 1 algo.
> FPGA?
then that's half-dedicated.
I read articles about RSA accelerators in ASICs or full-custom designs.
DES or RC5 cores might be available but not much else.

> > > What's a 64-bit CPU good for, compared to a 32-bit one? It's not
> > > necessarily faster,
> > it can be, as it treats wider data.
> That's wrong in many cases. Wider data types don't buy you anything if
> the range or precision of your numbers doesn't grow. But you need more
> memory to store a variable (which will slow down the program), or you'll
> have to work with partial registers (which may slow down the CPU). In some
> cases, SIMD can make the CPU perform better (numeric kernels, multimedia
> stuff), but a more general application with lots of (integer) add, shift,
> compare and pointer operations won't run faster on a 64-bit machine.

then, computation time can be reduced by grouping CPUs.

> > > but it can handle large working sets. Therefore
> > > I'd rather focus on scientific applications, databases and so on.
> > don't worry, this will follow naturally, but how many scientists do you
> > know around F-CPU ?...
> Do I have to *know* them? ;)
that can help.

For example, a CFD scientist has explained me how the newest algos
work, and they WILL benefit from very wide SIMD cores (contrarily
to what nicO said). the limiting factor is of course the RAM bandwidth,
as it deals with gigabytes of 3D data... but i have developped
a strip-mining stategy that helps :-)

> > > [...]
> > > > The case of dnet is looking different but i can't involve myself
> > > > in this now. The case of the SIMD shift has been proved and there
> > > > does not seem to be any difficulty in implementing it with F-CPU,
> > > > we simply disagree on a "small" implementation detail :-)
> > > Huh? No difficulty?
> > huh, i'll try to make my own shifter... whenever i can :-)
> With all operations performed in one cycle? I already violated the
> 6G/10T rule in my design.
if you can't fit, just pipeline. SHL has some pretty long wires and they
get longer as the register width increases : you can't stand the frequency
if the shifting distance is too long.

Maybe a 2-speed shifter is possible ? below 32 bits, it will work in 1 cycle,
and need 2 cycles for 32 and 64 bits ? this will obviously depend on the
SIMD+SIZE bits, so it is deterministic at decode time and possible (like the
add and multiply instructions).

In another post, you wrote :
> Today I examined the omega network again, and I think it's able to perform
> the `real' SIMD rotate operations. But I'll have to rewrite the control
> and masking logic, which will take some time. Don't expect a new version
> until the end of june (this year, of course).
I have a simple strategy in mind but have almost no decent computer environment :
i'm making a Linux "personal distro" (based on LFS) because i need to better
control my working environment. Before i have a working X display, i can't
develop much :-(


>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE (who's still doing his Linux Factory System ;-P)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/