Compiling on Tru64Unix 4.0f

[pjot]

Well, you are wrong... :-)

At line 2872 in 'newlisp.c' you cast to long:

*floatNumber = (long)cell->contents;}

I have changed the (long) to (int), and guess what? The (inc 'a -1) works now.

*floatNumber = (int)cell->contents;}

Tonight I will test more. Probably all LONGs should be switched to INTs.

Could you also add the '-ieee' compiler switch to 'makefile_tru64'?

[Lutz]

That's the one in getFloat() doing the conversion. There are lots of (long) casts in nl-math.c too, you will see. Lets hope that all this streightens out the port to tru64.

Lutz

[pjot]

Well, I can try again to compile with

Code: Select all

-protect_headers default -xtaso_short 

compile flags, which will force a 32-bit compilation. That denifitively should solve the 8byte/4byte stuff.

But it would ne nice to run in 64-bit mode!

[pjot]

Just ran the 'qa_dot' again, the result is much better:

Testing contexts as objects and scoping rules ...


TESTING FINISHED WITH ERRORS:

>>>> 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

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

> ring...

So 12 functions left, instead of the 23 yesterday, which means that 11 functions have been solved by changing that cast to (int).

I will run through the other sourcefiles of newLisp tonight to see what is going on.

Peter

[Lutz]

Looking through some of the array functions I cannot see anything obvious. The good news is the "ring ..." at the end, which is from testing the timer functions, so signals seem to work.

I want to do a development release on the weekend. If there is anything you want me to merge in just tell me, where I can get it like you did before.

Lutz

[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 all

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 all

(= (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 all

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 all

#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 all

#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 all

(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 all

(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.

[pjot]

Maybe it has to do with those pointer sizes again? I see that a 'allocMemory' returns a void pointer (8 bytes), but in the 'p_array' function (nl-list.c) the allocMemory is casted to UINT, which is 4 bytes.

Still that does not illuminate why 1-dimensional arrays with a large size can be created. Also many other newLisp functions should crash, which is not happening. Indeed it must be something else then.

This works:

Code: Select all

(set 'a (array 3))

This crashes:

Code: Select all

(set 'a (array 4))

Also I found the Compaq C Programmers Guide online:

http://h30097.www3.hp.com/dtk/Compaq_C_ ... CU0040.HTM

Peter

[Lutz]

May be memory is segmented, how is it wiht larger strings?

(dup "A" 1000000)

or

(read-file "biggerfile.txt")

That would also force a bigger contiguos memory area to be taken.

Lutz

[newdep]

Yoooo Pjot, some addons...

(dup "a" 10000)
does not show anything..

where (dup "a" 2047) is the maximum that works..

(read-file "core") does work though i did not test it upto the
complete size of 45948928 bytes over telnet ;-)

Norman.

[Lutz]

May be the memory is segmented in 2k increments somehow? I will have a look into the Compaq tru64 docs this weekend.

Lutz

[newdep]

Lets check that...
Pjot what does the /etc/sysconfigtab show up with?
and drop a vmstat output..

Norman.