Trying to get a NN code going

Richard A. O'Keefe ok@atlas.otago.ac.nz
Tue, 2 Mar 1999 13:33:09 +1300 (NZDT)


	The Clean compiler does not automatically inline functions,

Ah.  That's a bit disappointing.  These days, C compilers _do_, and
Ada compilers even offer cross-module inlining.

Naturally, the functions that need to be inlined as tight loops
(and which the C compiler _does_ inline) are recursive functions
in Clean, so I _can't_ rewrite them as macros.

	The compiler does not unroll loops and does not have an
	instruction scheduler.
	
I didn't expect it to unroll list-based loops, although there are
said to be (experimental) functional compilers that can.  I _do_
expect any compiler for today's CPUs (Sparc, Alpha, Mips, PowerPC,
Pentium family) to put a fair bit of effort into instruction
scheduling.  It's hard, of course, which is why Mercury uses gcc
to do it.

At a rough guess, based on this information, the best I could possibly
hope for (with arrays and uniqueness) would be Clean code a factor of
4 slower than C.

	When a Clean program dies with a segmentation violation there
	are 2 possible causes:  a stack overflow or an incorrecly used array
	index.

I knew that these were possible causes, I did not know they were the
only possible causes.  On any particular UNIX system, it should be
straightfoward to catch the SIGSEGV and check whether it was a stack
overflow or not.  It would certainly be so on Solaris, which is the
UNIX I was using.  That would be useful information to have, because
my reponse to stack overflow should be
    - check for unbounded recursion
    - recompile with increased stack size
whereas
my response to array subsecript error should be
    - check array subscript uses.

	Array indices can be checked at runtime by enabling the Code
	Generator option Check Indices in the CleanIDE, or by using -ci with
	clm.
	
This is great news, but why isn't in the man page?
clean/man/man1/clm.1
starts with
    .TH CLM 1 "May 14 1998" "Version 1.3"
and contains no mention of any -ci option at all.
What's more, when I actually try to _use_ the 1.3 compiler, it says
    unknown option: -ci

	>I hoped that the Macintosh version might be a bit better, but when
	>I try to _compile_ the program on a PowerMac 7600/120 running MacOS 8.1,
	>an Errors window pops up, containing
	>
	>    Fatal Error in comsupport:TH_Alloc "Insufficient Memory"
	
	The CleanCompiler needs to be resized with the Finder or ResEdit
	(SIZE resource).  You can quit the CleanCompiler by pressing any
	key, or by quiting the CleanIDE.
	
Yes, but what should I resize it *TO*?  Is there any rule of thumb that
relates source complexity to memory requirements?

	You can get a stack trace of the top of the stack on the
	PowerMac or Windows by enabling the time profiler

GREAT!  Is this going to be available in UNIX versions soon?

	You can insert print statements using the functions in StdDebug.

Thanks to all the people who've told me about this.  trace_n helped me
find the problem just like that (snaps fingers).