Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!postnews2.euro.net!news.wanadoo.nl!not-for-mail
From: mhx@iae.nl (Marcel Hendrix)
Subject: Re: ANN: All FIPS 180-4 Secure Hash Algorithms in ANS Forth
Newsgroups: comp.lang.forth
Message-ID: <71899416028434@frunobulax.edu>
Date: Sat, 19 Jan 2013 09:14:32 +0200
References: <3f70f49b-8bf3-456a-aa26-1fcda9666136@googlegroups.com>
X-Newsreader: iForth 2.0 console (October 21, 2006)
Lines: 66
Organization: Wanadoo
NNTP-Posting-Date: 19 Jan 2013 08:14:03 GMT
NNTP-Posting-Host: s529d937f.adsl.online.nl
X-Trace: 1358583243 dr6.euro.net 249 82.157.147.127:60059
X-Complaints-To: abuse@wanadoo.nl
Xref: csiph.com comp.lang.forth:18890

jzakiya@gmail.com writes Re: ANN: All FIPS 180-4 Secure Hash Algorithms in ANS Forth

> On Thursday, January 17, 2013 3:36:30 PM UTC-5, Marcel Hendrix wrote:
>> jzakiya@gmail.com writes Re: ANN: All FIPS 180-4 Secure Hash Algorithms in ANS Forth
[..]
> Thanks for posting the test results.
> The answers are correct.

I am suggesting that you add the expected results of the build-in tests 
to the file. The (conditionally compiled) test words can then auto-check 
if there was any problem. It is not always possible or useful to do that, 
but here it certainly is.

> By the way, I did a version that didn't place the message block words on that 
> stack, but did it in memory, and it's appreciably slower than using the stack.
> PICKing off the stack is much faster than @|! into memory arrays.

OK. I think you remember that I showed a version for SHA-512 which does 
not use PICK and runs the benchmark for EX3 in 10.7 seconds. Your latest
published source (with PICK) compiles on iForth64 and the EX3 bench 
takes about 20 seconds. 

> But now that you have a reference working versions, you can always play around
> with them to see if you can do it faster in a more IForth specific manner.

I can get the EX3 bench down to 17 seconds by *removing* all MACRO 
and ]L and [ ] constructs... Isn't that nice, not even is CODE .. 
ENDCODE obsolete, but also compiler hints are rapidly becoming 
unnecessary. 

It would be interesting to do a straightforward translation of the 
C-description to see if the 'Forth thinking-style' is at all necessary 
to get those results. 
I suspect that it suffices to remove pointer-chasing nighmares and 
locals for the ~20 seconds result. 

> FYI, when I originally did SHA-1 and SHA-256 back in 2000-3 I did ICODEd versions 
> for SwiftForth and VFX that are nearly twice as fast as their ANS Forth versions, 
> but these were specifically tuned to Intel P4 chips back then. 

It would be interesting to know what was P4-specific in the ICODE ? 
I find that my assembly language tricks from the pre-P4 days still 
work. At some point it became important to not mix code and data, 
that's about it.

I have never understood why push and pop are slower than memory 
references on Intel chips. It must be something with changing the 
stack pointer, because other languages use the stack all of the 
time for their locals. However, if it were that, it would suffice 
to use e.g. rbp for the Forth stack. I have never seen reports 
that that is fundamentally faster then using rsp.

>                                                                A decade later 
> these algorithms still must be done serially and can't take 
> advantage of parallel operations in multi-core/threaded cpus.

I don't think time has anything to do with it. This algorithm is 
*designed* to be serial and slow -- you don't want brute force 
cracks to succeed.

I think we will see microcontrollers with on-board FPGA, RSN. 
Maybe the FPGA peripheral will find a way to the desktop. Forth 
has the flexibility and extensibility to use these things :-)

-marcel