Compiling on Tru64Unix 4.0f

[pjot]

Well, I cleaned up and started again to measure the progress.



-makefile_tru64 ---> add the "-ieee" compilerflag so (test-pmt) passes.



makefile_tru64 looks like this now:

# makefile for newLISP v. 8.x.x on HP Tru64Unix

#

#



OBJS = newlisp.o nl-symbol.o nl-math.o nl-list.o nl-liststr.o nl-string.o nl-filesys.o

        nl-sock.o nl-import.o nl-xml.o nl-web.o nl-matrix.o nl-debug.o tru64.o pcre.o



CFLAGS = -ieee -pedantic -c -O2 -DNANOSLEEP -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET



CC = cc



default: $(OBJS)

#       $(CC) $(OBJS) -taso -lm -lrt -ldb -Lffi-tru64-5.1 -lffi -o newlisp

        $(CC) $(OBJS) -taso -lm -lrt -ldb -Lffi-tru64-4.0 -lffi -o newlisp

        strip newlisp



.c.o:

        $(CC) $(CFLAGS) $<



$(OBJS): primes.h protos.h makefile_tru64

Changed the following:



-'newlisp.c' ---> line2872 cast to (int)



-'nl-math.c' ---> line 123 cast to (int)

-'nl-math.c' ---> line 138 cast to (int)

-'nl-math.c' ---> line 139 cast to (int)

-'nl-math.c' ---> line 140 cast to (int)

-'nl-math.c' ---> line 143 cast to (int)

-'nl-math.c' ---> line 144 cast to (int)

-'nl-math.c' ---> line 145 cast to (int)

-'nl-math.c' ---> line 146 cast to (int)

-'nl-math.c' ---> line 147 cast to (int)

-'nl-math.c' ---> line 148 cast to (int)

-'nl-math.c' ---> line 151 cast to (int)

-'nl-math.c' ---> line 279 cast to (int)

-'nl-math.c' ---> line 573 cast to (int)

-'nl-math.c' ---> line 574 cast to (int)

-'nl-math.c' ---> line 745 cast to (int)

-'nl-math.c' ---> line 1595 cast to (int)





As a result, 12 functions are left to test:

>>>> array-list failed nil

>>>> array? failed nil

>>>> binomial failed nil

>>>> exec failed nil

>>>> fv failed nil

>>>> int failed nil

>>>> integer failed nil

>>>> net-receive-udp failed nil

>>>> net-send-udp failed nil

>>>> npv failed nil

>>>> semaphore failed nil

>>>> share failed nil

---------------------------------



Started to work on the EXEC statement. I found that the C-function 'fgetc' (which is used in 'nl-filesys.c' lines 407-431 function 'readStreamLine') returns EOF when encountered an error or a signal. Unfortunately, the 'fgetc' function is interrupted by Tru64Unix continuously, thereore generating "Interrupted system call" or the EINTR signal all the time.



This means that sometimes the stream is read, sometimes not.



So, it was necessary to adjust the function 'readStreamLine' in a way, that it will continue when EINTR was received. I did it like this:

Code Select Expand


char * readStreamLine(STREAM * stream, FILE * inStream)
{
int chr;

openStrStream(stream, MAX_STRING, 1);

do { <--------------------------------------------added
errno = 0; <-------------------------------------added

while((chr = fgetc(inStream)) != EOF)
    {
    if(chr == 'n') break;
    if(chr == 'r')
        {
        chr = fgetc(inStream);
        if(chr == 'n' || chr == EOF) break;
        }
    writeStreamChar(stream, chr);
    }

} while (errno == EINTR);   <------------------------added

if(chr == EOF && stream->position == 0) return(NULL);
return(stream->buffer);
}


Ugly, but it works. I hope you have a better idea on how to change this. After a "./newlisp qa_dot", this is the result:

>>>> array-list failed nil

>>>> array? failed nil

>>>> binomial failed nil

>>>> fv failed nil

>>>> int failed nil

>>>> integer failed nil

>>>> net-receive-udp failed nil

>>>> net-send-udp failed nil

>>>> npv failed nil

>>>> semaphore failed nil

>>>> share failed nil

So the EXEC statement works now. Only 11 functions left... :-)



I will post the adjusted newLisp package with the changes I mention here before the weekend. If you can approve and merge these changes....??



Continuing with the other statements now...

--

[newdep]

Can you test 5.1b ? I like to test it on the DS25 also oh yes and the ES40

aswell... Better then cooking eggs on it ;-)



Thanks! Norman.



(hahahaha..great pjot... :)

[pjot]

Yeah yeah yeah... laugh at me! Now it is a matter of principles... :-)



Anyway, I found the reason why the newLisp INT and INTEGER statements fail. They actually fail on these tests:

Code Select Expand


(= (integer "10000000000")  2147483647)
(= (integer "-10000000000") -2147483648)


newLISP v.8.5.8 on Tru64Unix, execute 'newlisp -h' for more info.

> (integer "10000000000")
1410065408


In the file 'nl-string.c' the function "CELL * p_integer(CELL * params)" (lines 803-835) concludes with:

Code Select Expand


return(stuffInteger((UINT)strtol(intString,(char **)0,(int)base)));


As you may suspect, the pain is in the 'strtol' C-function, which converts a string to a long! <sigh>



If I plainly replace the 'strtol' for a 'atoi' then the newLisp statement REPLACE does not work. So I have to think of a workaround for the 'strtol' situation...



Anybody any ideas?

[Lutz]

You could do the following, forcing 32bit behaviour:



#ifdef TRU64

long result;



result = strtol(....)



result = result > 2147483647 ? 2147483647 : result;

result = result < -2147483648 ? -2147483648 : result;



return(stuffInteger((int)result));

#endif



Lutz

[pjot]

I found the following trick:

Code Select Expand


#ifdef TRU64
if (strtol(intString,(char **)0,(int)base) > 2147483647)
    return(stuffInteger(atoi(intString)));
if (strtol(intString,(char **)0,(int)base) < -2147483648)
    return(stuffInteger(atoi(intString)));
#endif
return(stuffInteger((UINT)strtol(intString,(char **)0,(int)base)));
}


This is at the end of the 'p_integer' function. If I run 'newlisp qa_dot', then  this is the result:

>>>> array-list failed nil

>>>> array? failed nil

>>>> binomial failed nil

>>>> fv failed nil

>>>> net-receive-udp failed nil

>>>> net-send-udp failed nil

>>>> npv failed nil

>>>> semaphore failed nil

>>>> share failed nil

Only 9 left.



Nice exercise by the way... :-)

[pjot]

Hi Lutz, I did not see your posting, I will test your code now...

[pjot]

OK works well!



:-)



Continuing report:



- Changed file 'nl-string.c' lines 836-848 to ensure C integer return value

Code Select Expand


#ifdef TRU64
/* if (strtol(intString,(char **)0,(int)base) > 2147483647)
    return(stuffInteger(atoi(intString)));
if (strtol(intString,(char **)0,(int)base) < -2147483648)
    return(stuffInteger(atoi(intString))); */

/* Suggestion by Lutz Mueller */
result = strtol(intString,(char **)0,(int)base);

result = result > 2147483647 ? 2147483647 : result;
result = result < -2147483648 ? -2147483648 : result;
return(stuffInteger((int)result));
#endif


You may choose which solution fits best... :-) the variable 'result' was declared at the top of the function.



Continuing...

[pjot]

Found the cause for the newLisp 'share' statement.



The test for 'share' looks like this:

Code Select Expand


(if (< opsys 5)
(unix-test-share)
(win32-test-share))


But the 'opsys' for Tru64Unix is 9. According to this test, the code for Windows is executed and this delivers a 'nil'.



Rewrote the test to:

Code Select Expand


(if (or (< opsys 5)(= opsys 9))
(unix-test-share)
(win32-test-share))


Now after a 'newlisp qa_dot' the 'share' statement is working.



----



The UDP tests do not work because they rely on semaphore. Rewriting the semaphore test for opsys=9 did not solve it. I will hunt it down tomorrow.



Good night, 8 functions left.

[pjot]

Semaphore works now. UDP works.

[pjot]

Fixed the funancial functions 'npv', 'binomial' and 'fv'.



It appeared that the C-function pow() has another prototype on Tru64. The protoype is: pow(double, double).



So I had to cast the second argument of 'pow' to (double).



After running "newlisp qa_dot", this is the result:

TESTING FINISHED WITH ERRORS:



>>>> array-list failed nil

>>>> array? failed nil



newLISP v.8.5.8 on Tru64Unix, execute 'newlisp -h' for more info.



> ring...

What worries me, is that newLisp exits immediately after the "ring"... also a fork exits newLisp. This is not correct behaviour, the prompt of newLisp should remain.



What happens when a call to 'fork' or 'timer' is invoked in newLisp? Any idea why I arrive at the command prompt?



Peter

------

[Lutz]

Congratulations Peter, almost there!



Both, the timer and the fork send a signal. The timer sends a SIGALRM and the forked child process sends a SIGCHLD to the parent when finished.



It looks like the signal handlers defined and initialized at the beginning of newlisp.c do not work on true64.



Lutz

[pjot]

OK thanks! I'll see if there is a trick for those signal handlers.



In the meantime I found the last issue with the ARRAY. It appears to be caused by the fact that newLisp expects pointers to be 4 byte in size. For Tru64 Unix however, pointers are of 8 byte size.



If I compile with -xtaso_short, forcing 4-byte pointers, so compiling as 32bit, all array statements work perfect. But all of a sudden many other statements do not work anymore (like the 'format' statement, but also 'log', the UDP statements etc)



If I compile as 64bit, arrays with large dimensions will cause a coredump.



This was really a pain to find out. But anyway I know the cause now.



------------



So concluded, 2 jobs left: fix the array stuff and look at the signal handlers.



The 'timer' function does work, but after it carried out the task newLisp just exits. The same with 'fork': it works, but will exit newLisp.



The TTYLOCK.LSP demo of Norman, which uses signals extensively, works OK with 64bit newLisp. So it is strange that newLisp exits on 'fork' and 'timer'.



Tomorrow I will try to solve the last issues as far as possible and post the tar.gz with a list of changes.



Peter

[pjot]

Those signals from 'fork' and 'timer' work now, I needed to link with the BSD library (option -lbsd). So after a 'timer' or a 'fork' I remain in the newLisp prompt.



So I am only left with those arrays. Is there some 32bit specific stuff you do with memory and arrays?



Peter

[Lutz]

Pretty much everything in the code relies on pointers and int's having both 4 bytes, and all would fall apart immedeately if not. 4 byte pointers are used to address symbols, to link lisp cells and to store string data.



There must be something else going on with arrays and I look into it, when I am back at home tomorrow night.



Lutz

[pjot]

OK thanks! In the meantime I made some observations:

newLISP v.8.5.8 on Tru64Unix, execute 'newlisp -h' for more info.



> (array 3 3 (sequence 1 6))

((1 2 3) (4 5 6) (1 2 3))

> (array 4 4 (sequence 1 6))

Segmentation fault (core dumped)

So with (larger) multidimensional array's a core is created. Therefore, newLisp passes the '(test-array)' in 'qa_dot' because the array in there has a small size. But the '(test-array-list)' fails because of the larger dimensions of the declared array.

> (array 100 (sequence 1 5))

(1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2

 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4

 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1

 2 3 4 5)

> (set 'a (array 100 (sequence 1 5)))

Segmentation fault (core dumped)

So creating a 1 dimensional array is no problem, all sizes seem to work. But assigning the result to a variable cores newlisp.