11 Apr
2012
11 Apr
'12
2:26 a.m.
Peter Coghlan wrote:
Nice to hear..
The mms default call to cc is like this:
cc /def=("FEAT_NORMAL","HAVE_CONFIG_H","FEAT_GUI_MOTIF" )
/opt/prefix=all
/include=([.proto],decw$include:) BUFFER.C
Interestingls help cc/opt onli has those documented options:
CC
/OPTIMIZE
/OPTIMIZE[=option] (D)
/NOOPTIMIZE
Controls whether or not the compiler performs code optimization.
/OPTIMIZE has the following options:
[NO]DISJOINT Directs the compiler to optimize the generated
machine code.
[NO]INLINE Specifies whether the compiler is allowed to perform
the function inline optimization.
So my question is, what should /opt/prefix=all so in this case?
Yes, I have compiled the entire source with the crypto features commented
out, and yes I can compile blowfish.c with that cmdline:
$ cc /def=("FEAT_NORMAL","HAVE_CONFIG_H","FEAT_GUI_MOTIF" )
/NOOPT
/include=([.proto],decw$include:) BLOWFISH.C
..and it compiles sha256.c too.
Is there further documentation about the compiler optimizations somwhere
available?
Kind Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
There are orher problems now with that VIM Source, the files blowfish.c and
sha356.c take very very much time to compile. I do have an account on
Vaxmans VAX7000/820 and even on this machine the compiling was not done after
13hrs of CPU Time. SHA356.c behaves pretty much similar.
I'll look later this day if the compiling gets done on this machine, on my
VS4000 the same process is running now for 12hrs on the CPU and the
VS4000/90 isn't the slowest VAX so far as I know...
Well, my curiosity got the better of me. I downloaded VIM73-69 for VMS and
attempted to compile blowfish.c on my VAX 4000/100A with VAX/VMS 7.1 and
DECC V6.4-005. I don't have MMS or MMK installed so I had to hack a little to
make it work.
I found that after some seconds work, the compiler went into a CPU bound loop
and seemingly did nothing useful after that (unless it is thinking hard and
will come up with something useful some time from now!).
The source is not large so I was able to find that the part that the compiler
was having difficulties with was these two lines of macros in bf_e_block():
F1(0) F2(1) F1(2) F2(3) F1(4) F2(5) F1(6) F2(7)
F1(8) F2(9) F1(10) F2(11) F1(12) F2(13) F1(14) F2(15)
I found that if I commented out F1(10) F2(11) F1(12) F2(13) F1(14) F2(15)
the compile would complete in just under a minute.
Next I tried commenting out just F2(11) F1(12) F2(13) F1(14) F2(15)
and then the compile completed in around 7 minutes. It took about the same time
if I only commented out F1(12) F2(13) F1(14) F2(15).
If I commented only F2(13) F1(14) F2(15) the compile took nearly two hours!
Finally, it dawned on me to try compiling the original code with /NOOPTIMISE
and this completed in 30 seconds!
So, it appears that something in those two lines is causing the optimiser to
spend way too much time doing something.
At least the good news is that if you compile blowfish.c (and perhaps sha356.c)
without optimisation, it should be possible to get it done in a reasonable
amount of time. Maybe the compile you are currently running will also complete
eventually.
Regards,
Peter Coghlan.