HP-UX 11i porting challenges: sigcontext structure really different ...

Hi again -

(I am still trying to get SBCL to work on HP-UX 

So I have been hacking and tweaking and ... got stuck with compiling  
hppa-linux-os.c (which I now named hppa-hpux-os.c).

The linux version says:

os_context_register_t   *
os_context_register_addr(os_context_t *context, int offset)
{
     if (offset == 0) {
         /* KLUDGE: I'm not sure, but it's possible that Linux puts the
            contents of the Processor Status Word in the (wired-zero)
            slot in the mcontext. In any case, the following is
            unlikely to do any harm: */
         static int zero;
         zero = 0;
         return &zero;
     } else {
         return &(((struct sigcontext *) &(context->uc_mcontext))- 
 >sc_gr[offset]);
     }
}

Now, looking at the HP-UX include files (deep, very deep down inside  
the /usr/include hierarchy  I find:

/usr/include/machine/sys/sigcontext.h

PPC alien-funcall bug with system-area-pointer and (unsigned 64) arguments

I recently stumbled across an odd problem with ALIEN-FUNCALLs on PPC
Linux. It appears that if an (unsigned 64) argument follows a
system-area-pointer then the long long and any following arguments
will be shifted one word either forward or backwards, depending on the
alignment of the long long.

Attached is some code that demonstrates the bug, here is the output on
my system:

(running SBCL from: /home/joshe/sbcl)
This is SBCL 1.0.16.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
jre_test_reg_pl           ptr1=0xaaaaaaaa long1=ffffffff10023e78
jre_test_reg_pli          ptr1=0xaaaaaaaa long1=ffffffff11111111 int1=10023e78
jre_test_reg_pil          ptr1=0xaaaaaaaa int1=11111111 long1=00000000eeeeeeee
jre_test_reg_pili         ptr1=0xaaaaaaaa int1=11111111 long1=00000000eeeeeeee int2=ffffffff
jre_test_reg_ipl          int1=11111111 ptr1=0xaaaaaaaa long1=00000000eeeeeeee
jre_test_reg_lpl          long1=ccccccccdddddddd ptr1=0xaaaaaaaa long2=ffffffff10023e78
jre_test_stack_pl         (11111111 22222222 33333333 44444444 55555555 66666666) ptr1=0xaaaaaaaa long1=ffffffff10023ee8
jre_test_stack_pil        (11111111 22222222 33333333 44444444 55555555 66666666) ptr1=0xaaaaaaaa
int7=77777777 long1=00000000eeeeeeee
jre_test_overlap_pl       (11111111 22222222 33333333 44444444) ptr1=0xaaaaaaaa long1=ffffffff50c71537
jre_test_overlap_pil      (11111111 22222222 33333333 44444444) ptr1=0xaaaaaaaa int5=55555555 long1=00000000eeeeeeee

I've also attached a patch to tests/foreign.test.sh that adds a test

Re: HP-UX 11i porting challenges: sigcontext structure really different ...

Hi Thiemo -

Am 02.05.2008 um 05:02 schrieb Thiemo Seufer:
>
> No idea about sc_iaoq, but sc_gr is the array of saved general purpose
> registers. I guess the HP/UX equivalent lives in the struct siglocal/
> struct siglocalx mentioned above.
>
>
> Thiemo

Yep. You're right. Meanwhile I found the (C preprocessor) macro  
GetSSReg in HP-UX's /usr/include/pa/save_state.h on my machine that  
helps in accessing the register set on the HP PA-RISC machines.

Problem now is that the sc_gr equivalent on HP-UX is not an array but  
a struct. So, some work to do translate sc_gr[offset] to the HP-UX  
version ...

Best,
   Frank

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

HP-UX 11.11 porting challenge: Now in Assembler Land ...

Hi again -

Thanks to help from people here on the list I got past the compilation  
of hppa-hpux-os.c with just a few additions and changes:

In file hppa-lispregs.h I added:

#if !defined(GetSSRegAddr)
#define GetSSRegAddr(ssp, ss_reg) \
     ((UseWideRegs  
(ssp))                                                  \
     ? (ssp)->ss_wide.ss_32.ss_reg ##  
_lo                                 \
     : (ssp)->ss_narrow.ss_reg)
#endif

which helps to access the PA-RISC registers. Some digging revealed  
that ss_ioaq[0] (on Linux) equals ss_pcoq_head and ss_iaoq[1] is  
ss_pcoq_tail on HP-UX.

I also had to include <sys/ucontext.h> in hppa-hpux-os.h to make sure  
I do not get a imcomplete type dereferencing error.

Now while all this sounds good my next challenge is a very simple  
error message:

/opt/hp-gcc/bin/gcc -g -Wall -Wsign-compare -O3 -Dhpux - 
D_INCLUDE_HPUX_SOURCE -D_INCLUDE_POSIX_SOURCE - 
D_INCLUDE_XOPEN_SOURCE_EXTENDED -I.  -c -o hppa-assem.o hppa-assem.S
hppa-assem.S: Assembler messages:

Re: HP-UX 11.11 porting challenge: Now in Assembler Land ...

Frank Goenninger wrote:
> Hi again -
> 
> Thanks to help from people here on the list I got past the compilation  
> of hppa-hpux-os.c with just a few additions and changes:
> 
> In file hppa-lispregs.h I added:
> 
> #if !defined(GetSSRegAddr)
> #define GetSSRegAddr(ssp, ss_reg) \
>      ((UseWideRegs  
> (ssp))                                                  \
>      ? (ssp)->ss_wide.ss_32.ss_reg ##  
> _lo                                 \
>      : (ssp)->ss_narrow.ss_reg)
> #endif
> 
> which helps to access the PA-RISC registers. Some digging revealed  
> that ss_ioaq[0] (on Linux) equals ss_pcoq_head and ss_iaoq[1] is  
> ss_pcoq_tail on HP-UX.
> 
> I also had to include <sys/ucontext.h> in hppa-hpux-os.h to make sure  
> I do not get a imcomplete type dereferencing error.
> 
> Now while all this sounds good my next challenge is a very simple  
> error message:
> 
> /opt/hp-gcc/bin/gcc -g -Wall -Wsign-compare -O3 -Dhpux - 
> D_INCLUDE_HPUX_SOURCE -D_INCLUDE_POSIX_SOURCE - 
> D_INCLUDE_XOPEN_SOURCE_EXTENDED -I.  -c -o hppa-assem.o hppa-assem.S

Re: HP-UX 11.11 porting challenge: Now in Assembler Land ...

Frank Goenniger writes:
> Oh boy - SBCL now forces me to learn HP PA-RISC Assembler ??? Wow.  
> Anybody out there being a PA-RISC wizard?

If you have the HP-UX Documentation CD(s?), there is, or at least used to be, 
a PA-RISC reference book in there that I recall as being exceptionally good.

//Ingvar

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Rewrite of SB-SYS:WAIT-UNTIL-FD-USABLE

I've attached a patch that adds an implementation of
SB-SYS:WAIT-UNTIL-FD-USABLE which uses poll() directly instead using
serve-event. In the context of polling a single file descriptor
serve-event is unnecessary and slow since it involves adding and
removing a handler each time.
The patch is only for *nix systems, the old implementation is still
there for #!+win32.

I ran a comparison to the serve-event w-u-f-u and got this:

using serve-event:
  seconds  |   consed   |  calls |  sec/call  |  name  
---------------------------------------------------------
     2.249 | 44,303,176 | 93,509 |   0.000024 | SB-SYS:WAIT-UNTIL-FD-USABLE
---------------------------------------------------------
     2.249 | 44,303,176 | 93,509 |            | Total

with poll():
  seconds  |   consed   |  calls |  sec/call  |  name  
---------------------------------------------------------
     1.204 | 12,282,280 | 96,365 |   0.000012 | SB-SYS:WAIT-UNTIL-FD-USABLE
---------------------------------------------------------
     1.204 | 12,282,280 | 96,365 |            | Total

--

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

diff --git a/package-data-list.lisp-expr b/package-data-list.lisp-expr

Plans for next release

Hi,

Just a note to say that I'd like to aim to make the next release
(which should happen towards the 25th of the month or so, as
previously) something of a beta for 1.1 -- which means that it would
be nice to sort out recent regressions, build failures on certain
platforms, and so on.  If there are items of that general nature that
haven't been fixed or acknowledged, then the next fortnight or so
would be a good time to send patches, or remind people that patches
have already been sent...

Best,

Christophe

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: Plans for next release

On Sat, May 3, 2008 at 11:49 AM, Christophe Rhodes <csr21 <at> cantab.net> wrote:

>  Just a note to say that I'd like to aim to make the next release
>  (which should happen towards the 25th of the month or so, as
>  previously) something of a beta for 1.1 -- which means that it would
>  be nice to sort out recent regressions, build failures on certain
>  platforms, and so on.  If there are items of that general nature that
>  haven't been fixed or acknowledged, then the next fortnight or so
>  would be a good time to send patches, or remind people that patches
>  have already been sent...

On a related note, I'm going to revert the ANY-REG patch, which was
wrong (but as far as I can tell harmless: in cases where it matters,
the compiler will refuse to generate the code due to missing move
VOPS, etc.) -- as soon as I find the time to extract the test case
from Elephant. (Or if someone else does it...)

I also want to merge a workaround for the dynamic extent value cell
bug, unless I manage to fix it during the next week or so. (Requiring
an explicit SB-C::STACK-ALLOCATE-VALUE-CELLS optimize declaration, so
that we can use it internally in performance critical bits, as can
brave users, but so that it cannot accidentally return garbage to an
innocent user.) The workaround is already written, but I want to give
an actual fix one last try.

Those are the two outstanding items on my list.

If time permits I would also like to address some of the concurrent
hash table access issues reported by Attila, but I'm not too
optimistic on that score. The right place to lock for obsolete

Re: Rewrite of SB-SYS:WAIT-UNTIL-FD-USABLE

On Sat, May 3, 2008 at 11:13 AM, Stelian Ionescu
<stelian.ionescu-zeus <at> poste.it> wrote:
> I've attached a patch that adds an implementation of
>  SB-SYS:WAIT-UNTIL-FD-USABLE which uses poll() directly instead using
>  serve-event. In the context of polling a single file descriptor
>  serve-event is unnecessary and slow since it involves adding and
>  removing a handler each time.
>  The patch is only for *nix systems, the old implementation is still
>  there for #!+win32.

The numbers are nice, and the code looks good at a glance, but there
seems to be a loss of fuctionality here: if ADD-FD-HANDLER has been
called, W-U-F-U should run those handlers when it can. This doesn't
seem to happen anymore with your patch. At minimum you should check it
other handlers exist, and use the old code in that case.

By the way, it would be nice if you could post the benchmark code you used.

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone