AKCL-615 on Sun, hp700, RS6000, I386, Mips

[berglas@cs.uq.oz.au]

I have just finished porting AKCL 1-615 to a number of platforms and here is
a list of successes and problems that I have encountered.


SUN4
====

This made perfectly, using suns old (free, non ANSI) compiler.
However, I found that 
  (concatenate 'string "0" "1" ... "99")
produced "too many parameters".  si:string-concatenate works fine.
Suggestion:- As the si: version is undocumented and non standard, why
not make a special case for (concatenate 'string ...) and call the si:
function in that case, I would think that it would be *much* faster
than the untyped, element by element copy done in the standard
version.

Also (print (+ (expt 1234567 89) 1.1)) does not report the floating
point overflow propwely.


HP700
=====

As sacco@mga.com noted, the line definition of HAVE_AOUT in hp800.h is
wrong, 	I could not see how it could ever be useful so simply removed
it.  (This is defined in bsd.h).  The system then works fine.


RS600/RIOS
==========

This worked well.  I like the fact that it does not use the stratified
garbage collection by default, ie. it does not need the mprotect
system call loaded unless additional performance is required.  We do
not need the performance, and am glad that we do not have to consider
the implications of hacking the kernal.

However, an old problem caused unessesary grief. A user complained
that the system does not work.  It turned out that the problem was
that the machine ran out of disk space during si:save-system. Could
the return status of write() be tested, if it does fail an
error message and the deletion of the half saved file would be great.


Mips/RISCos
===========

This would not make under AKCL-615.  It died while making raw_kcl,
while loading "../autolad.lsp with
  "~?~&" is not of type list
and then recursing through the errror handler with "the variabe + is
unbound". dbx suggested that the problem was in init_init...read_object.

hikichi@srac2.sra.co.jp has just posted patches to the mail group that
apparently make AKCL-615 using gcc, and I would suggest that that
approach be used.  However, I the following was my hack which may be
of interest to those who don't have a gcc handy (in "[]"s).

[After hacking around I added ]
[	(print "AJB test")]
[	(print (defun fooo () 'ooof)) ]
[	(print (fooo))]
[to export.lsp, the first file loaded, in order to see what sort of]
[things were working.  The last expression caused  a segmentation]
[violation in funcall]
[line 286.  Traces show that the gbc had never been invoked, and that]
[the fun parameter to funcall was in fact fooo.  Adding (gbc t) before]
[the defun fooo worked fine until (fooo), when a slightly different]
[error was produced.  Using gcc is worse, it dies in alloc_object from]
[init_symbol, the second thing done in main.c.]
[]
[hikichi initial responce to my queries was "AKCL-530 works fine but 586 is bad".]
[I obtained both versions, and AKCL-530 does indeed make and simple]
[programs compiled and ran succesfully.  586 does]
[not, Initially because sigstack needed an #if guard in main.c ]
[(this has been added to vsn 615).  586 then dies with the same]
[symptoms as 615.  Just for fun I added (fooo) to vsn 530 export.lsp]
[and it did work fine.  The major difference between 530 and 586 was]
[the addition of the new bignum stuff, I was going to try to add]
[changes back one at a time but there were too many.]
[]
[However, AKCL-530 died on substancial application.  In particular, the]
[following does not compile:-]
[	(defun q () (unwind-protect (+ 1 2) 'b))]
[with cc complaining that ]
[	base[0]=Cnil;]
[or	if (base[10] != Cnil)]
[has incompatible types.  Previous experiance suggested that volatile]
[was the problem, and removing "-DVOL=volatile" made the error go away.]
[I tried adding the "-volatile" switch to cc which is supposed to make]
[everything volatile, but then strange errors about objects being]
[unknown size were issued.  Perhaps AKCL is upsetting it by the fact]
[that "object x" means that x is a pointer to an object, not an object]
[itself?  Anyway, the following program also causes cc grief:-]
[v.c: 	v() {int p; int *volatile q; p=q[3];};]
["Illegal indirection"                    ^]
[with removal of the volatile keyword fixing the problem.]
[]
[My final hack was to (setf compiler::*cc* "cc -O0 -G 0 "), ie. remove]
[the -DVOL..., turn off the optimiser and hope.  I note, however, that]
[akcl puts an -O after these switches anyway, hmm.  Compiling and]
[testing with (saftey 2) seems to work now anyway.  I have mailed mips]
[about the cc issues.]

Incidently, I noticed that autoload.lsp seems to rely on the previous
definition of keyword symbols to determine if modules had been loaded,
eg. :numlib.  Perhaps they should be put in a different package to
avoid possible conflicts with user defined keywords.


mp386 (INTERACTIVE UNIX 486)
============================

As noted earlier, I had to substitute gcc for mygcc in mp/makefile, as
I could find no file called mygcc.  I also added -traditional-cpp arg
to the CC command to make "putc ... undefined" loader errors go away.
AKCL-615 then made, but died for complex programs (only), indicating
problems with the fasd and index errors during compilation.
Following my experiance with the MIPS, I then tried to make AKCL-530
but it died while lisp compiling during the make. 

All problems where solved with AKCL-530 by removing the '-O' on the
'gcc', suggesting that the problem lay with gcc, which is not
surprising as I discovered that gcc-4.1 was only a test version!
I have no reason to believe that AKCL-615 would not make with gcc-3.39
"-O" provided that the minor patches above are made, and will try this
when I make time.
(I have not reported the error to gnu as it seems so obsucure that it
would be very difficult to track down.  The bug may be in akcl,
perhaps a missing volatile declaration is being detected by an
improved optimiser?)


THE MAKEFILES
=============

I have raised this before but the first thing that an AKCL user sees
is the make files and their confusing nature detracts from an
otherwise excellent product.  What do people think of
having the following changes made?

1) Copy, rather than ln in the old kcl files.

2) Do not copy the {lsp,cmpnew}/*.c files or the old main makefile.

3) Make a very_basic_kcl rather than different saved_kcl the first time,
   with only {lsp,cmpnew}/*.lsp files included (ie. not the .c ones).

Most of the original kcl files have been changed over they years, so
that the copy will take little extra space.  The advantage is that the
original kcl may be archived after the copy, there is no risk of
accidently modifying the original kcl source while hacking one of the
few remaining unchanged akcl files, and problems will not arise if the
directory trees are moved.

The original generated .c files don't work, so why bother compiling
them to make saved_kcl #1, in which case they need not be coppied.
The search for magic strings in these files to determine the pass is
obscure to say the least.  The use of Smakefile seams an unnecessary
complication, accidently just typing "make" during the first pass
seams a trap to young players that can easily be avoided.

Finally, as there are two distinct saved_kcl files, one compiled and
one interpreted, why not give them different names.  I once thought
that, having produced a saved_kcl that seemed to work, I had finished,
but it was the wrong one.  Both very_basic_kcl and raw_kcl
could automatically be deleted afterwards if disk space is a problem.

If one excludes the generated .c files, AKCL-1-615 is almost as big as
the original KCL anyway, so maybe the original authors could be
consulted about dropping the whole merging process anyway?

Incidently, kcn won't make at all under the current scheme under
the first pass until saved_kcl has been made under the second, so
cannot be used to try to localise errors.

Anthony Berglas
Rm 503, Computer Science, Uni of Qld
Ph 07 365 2812, Australia.