Re: Notes... The case for an open client

>> Byte-reversed adds are easy. You just wire the carry bits differently.
>
> That works if you are doing adds as 32 bit words. For a serial bit 
> stream you have the bits in one order for the increment then they get 
> chopped up and reordered before feeding in as the initial L values of 
> the first round. Feeding through something like a barrel shifter or 
> breaking each word into 4 individual bytes  would probably work but 
> it's still a little extra overhead.
>
> Do we accept the extra overhead for compatibility or find the easiest 
> possible implementation for the cores? Adaption of the software cores 
> to join the hardware project will be relatively easy and may even make 
> them faster.

What's preventing us from switching from byte-reversed to 
non-byte-reversed? (Why the hell is it byte-reversed anyway? Is it 
advantageous to do strange things to the key?)

Also, isn't it possible to recode the client to internally not bother 
(much) with byte-reverse adds (until it overflows by 2^32)? Aren't all 
blocks 2^32, at the moment, anyway? (I don't see an option for it)

The core should also be able to tell the client its own MIN_ITERATIONS 
(anyone fancy a 5-pipe?), recommended iterations (for cores which may 
have large init overheads), and any necessary alignment (as a power of 
2).

I'm not sure how 1-bit-serial hardware is supposed to work.

- Purr

_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware