Re: MPE Port

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * libobjc/thr-dce.c (__objc_thread_set_priority): PRI_FG_MIN_NP is not
	  available in all DCE ports. If not defined, return 0.
	  (__objc_thread_get_priority): If PRI_FG_MIN_NP not defined, default
	  to OBJC_THREAD_INTERACTIVE_PRIORITY.

*** egcs/libobjc/thr-dce.c	Mon Aug 30 21:50:50 1999
--- egcs-ss/libobjc/thr-dce.c	Mon Aug 30 21:53:02 1999
***************
*** 79,84 ****
--- 79,85 ----
  {
    int sys_priority = 0;
  
+ #ifdef PRI_FG_MIN_NP
    switch (priority)
      {
      case OBJC_THREAD_INTERACTIVE_PRIORITY:
***************
*** 99,104 ****
--- 100,108 ----
    else
      /* Failed */
      return -1;
+ #else
+     return 0;
+ #endif
  }
  
  /* Return the current thread's priority. */
***************
*** 107,112 ****
--- 111,117 ----
  {
    int sys_priority;
      
+ #ifdef PRI_FG_MIN_NP
    if ((sys_priority = pthread_getprio(pthread_self())) >= 0) {
      if (sys_priority >= PRI_FG_MIN_NP && sys_priority <= PRI_FG_MAX_NP)
        return OBJC_THREAD_INTERACTIVE_PRIORITY;
***************
*** 117,122 ****
--- 122,130 ----
  
    /* Failed */
    return -1;
+ #else
+   return OBJC_THREAD_INTERACTIVE_PRIORITY;
+ #endif
  }
  
  /* Yield our process time to another thread. */

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * libobjc/thr-dce.c (__objc_thread_set_priority): PRI_FG_MIN_NP is not
	  available in all DCE ports. If not defined, return 0.
	  (__objc_thread_get_priority): If PRI_FG_MIN_NP not defined, default
	  to OBJC_THREAD_INTERACTIVE_PRIORITY.

*** egcs/libobjc/thr-dce.c	Mon Aug 30 21:50:50 1999
--- egcs-ss/libobjc/thr-dce.c	Mon Aug 30 21:53:02 1999
***************
*** 79,84 ****
--- 79,85 ----
  {
    int sys_priority = 0;
  
+ #ifdef PRI_FG_MIN_NP
    switch (priority)
      {
      case OBJC_THREAD_INTERACTIVE_PRIORITY:
***************
*** 99,104 ****
--- 100,108 ----
    else
      /* Failed */
      return -1;
+ #else
+     return 0;
+ #endif
  }
  
  /* Return the current thread's priority. */
***************
*** 107,112 ****
--- 111,117 ----
  {
    int sys_priority;
      
+ #ifdef PRI_FG_MIN_NP
    if ((sys_priority = pthread_getprio(pthread_self())) >= 0) {
      if (sys_priority >= PRI_FG_MIN_NP && sys_priority <= PRI_FG_MAX_NP)
        return OBJC_THREAD_INTERACTIVE_PRIORITY;
***************
*** 117,122 ****
--- 122,130 ----
  
    /* Failed */
    return -1;
+ #else
+   return OBJC_THREAD_INTERACTIVE_PRIORITY;
+ #endif
  }
  
  /* Yield our process time to another thread. */

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message <4.1.19990906102936.00c80c40@garfield.dis.com>you write:
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * libobjc/thr-dce.c (__objc_thread_set_priority): PRI_FG_MIN_NP is 
  > not
  > 	  available in all DCE ports. If not defined, return 0.
  > 	  (__objc_thread_get_priority): If PRI_FG_MIN_NP not defined, default
  > 	  to OBJC_THREAD_INTERACTIVE_PRIORITY.
Seems to me that we can avoid #ifdefs in the actual funtions by providing
a default value for PRI_FG_MIN_NP (and possibly others if they are not
defined by your version of DCE threads).  If possible it helps to avoid
#ifdefing executable C code just from a readability standpoint.

What happens if you provide a default value of zero for those priority
values if they're not already defined?

[ Nope, I haven't forgotten about this stuff :-) ]

jeff

Re: MPE Port

[Mark Klein]

At 11:21 PM 10/25/99 -0600, Jeffrey A Law wrote:
>   In message <4.1.19990906102936.00c80c40@garfield.dis.com>you write:
>   > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
>   >
>   >         * libobjc/thr-dce.c (__objc_thread_set_priority): 
> PRI_FG_MIN_NP is
>   > not
>   >       available in all DCE ports. If not defined, return 0.
>   >       (__objc_thread_get_priority): If PRI_FG_MIN_NP not defined, default
>   >       to OBJC_THREAD_INTERACTIVE_PRIORITY.
>Seems to me that we can avoid #ifdefs in the actual funtions by providing
>a default value for PRI_FG_MIN_NP (and possibly others if they are not
>defined by your version of DCE threads).  If possible it helps to avoid
>#ifdefing executable C code just from a readability standpoint.
>
>What happens if you provide a default value of zero for those priority
>values if they're not already defined?

Actually, what's really missing is the pthread_setprio() call. That would
also need to be provided as a dummy procedure too. At that point, it
wouldn't matter what value were provided for PRI_FG_MIN_NP.

(Note the _NP indicates a non-portable feature and shouldn't be relied
upon outside of a specific platform).

>[ Nope, I haven't forgotten about this stuff :-) ]

No problem ... I'm busy too with my 'real' job. :-)

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991026064911.00c6ad40@garfield.dis.com >you write:
  > >Seems to me that we can avoid #ifdefs in the actual funtions by providing
  > >a default value for PRI_FG_MIN_NP (and possibly others if they are not
  > >defined by your version of DCE threads).  If possible it helps to avoid
  > >#ifdefing executable C code just from a readability standpoint.
  > >
  > >What happens if you provide a default value of zero for those priority
  > >values if they're not already defined?
  > 
  > Actually, what's really missing is the pthread_setprio() call. That would
  > also need to be provided as a dummy procedure too. At that point, it
  > wouldn't matter what value were provided for PRI_FG_MIN_NP.
Ah.  Given this new information, it seems to me like this stuff (the use of
pthread_setprio) should be autoconf'd instead of ifdefing away pieces of
it based on the existence of PRI_FG_MIN_NP.

jeff

Re: MPE Port

[Mark Klein]

At 07:54 PM 10/26/99 -0600, Jeffrey A Law wrote:


>Ah.  Given this new information, it seems to me like this stuff (the use of
>pthread_setprio) should be autoconf'd instead of ifdefing away pieces of
>it based on the existence of PRI_FG_MIN_NP.

Good point.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 07:54 PM 10/26/99 -0600, Jeffrey A Law wrote:


>Ah.  Given this new information, it seems to me like this stuff (the use of
>pthread_setprio) should be autoconf'd instead of ifdefing away pieces of
>it based on the existence of PRI_FG_MIN_NP.

Good point.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991026064911.00c6ad40@garfield.dis.com >you write:
  > >Seems to me that we can avoid #ifdefs in the actual funtions by providing
  > >a default value for PRI_FG_MIN_NP (and possibly others if they are not
  > >defined by your version of DCE threads).  If possible it helps to avoid
  > >#ifdefing executable C code just from a readability standpoint.
  > >
  > >What happens if you provide a default value of zero for those priority
  > >values if they're not already defined?
  > 
  > Actually, what's really missing is the pthread_setprio() call. That would
  > also need to be provided as a dummy procedure too. At that point, it
  > wouldn't matter what value were provided for PRI_FG_MIN_NP.
Ah.  Given this new information, it seems to me like this stuff (the use of
pthread_setprio) should be autoconf'd instead of ifdefing away pieces of
it based on the existence of PRI_FG_MIN_NP.

jeff

Re: MPE Port

[Mark Klein]

At 11:21 PM 10/25/99 -0600, Jeffrey A Law wrote:
>   In message <4.1.19990906102936.00c80c40@garfield.dis.com>you write:
>   > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
>   >
>   >         * libobjc/thr-dce.c (__objc_thread_set_priority): 
> PRI_FG_MIN_NP is
>   > not
>   >       available in all DCE ports. If not defined, return 0.
>   >       (__objc_thread_get_priority): If PRI_FG_MIN_NP not defined, default
>   >       to OBJC_THREAD_INTERACTIVE_PRIORITY.
>Seems to me that we can avoid #ifdefs in the actual funtions by providing
>a default value for PRI_FG_MIN_NP (and possibly others if they are not
>defined by your version of DCE threads).  If possible it helps to avoid
>#ifdefing executable C code just from a readability standpoint.
>
>What happens if you provide a default value of zero for those priority
>values if they're not already defined?

Actually, what's really missing is the pthread_setprio() call. That would
also need to be provided as a dummy procedure too. At that point, it
wouldn't matter what value were provided for PRI_FG_MIN_NP.

(Note the _NP indicates a non-portable feature and shouldn't be relied
upon outside of a specific platform).

>[ Nope, I haven't forgotten about this stuff :-) ]

No problem ... I'm busy too with my 'real' job. :-)

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message <4.1.19990906102936.00c80c40@garfield.dis.com>you write:
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * libobjc/thr-dce.c (__objc_thread_set_priority): PRI_FG_MIN_NP is 
  > not
  > 	  available in all DCE ports. If not defined, return 0.
  > 	  (__objc_thread_get_priority): If PRI_FG_MIN_NP not defined, default
  > 	  to OBJC_THREAD_INTERACTIVE_PRIORITY.
Seems to me that we can avoid #ifdefs in the actual funtions by providing
a default value for PRI_FG_MIN_NP (and possibly others if they are not
defined by your version of DCE threads).  If possible it helps to avoid
#ifdefing executable C code just from a readability standpoint.

What happens if you provide a default value of zero for those priority
values if they're not already defined?

[ Nope, I haven't forgotten about this stuff :-) ]

jeff

Re: MPE Port

[Mark Klein]

In message < 4.1.19990906102304.00c72c80@garfield.dis.com >you write:

>> + #undef CPP_PREDEFINES
>> + #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
>> -Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"

>You should move the -D definitions into a CPP_SPEC string to avoid ANSI
>namespace pollution.

Hmmm. I just lifted the HP-UX code and change hp9000s800 to hp3000s900.
I'll change it as you suggest.

>  > + 
>  > + /* HPUX needs gcc_plt_call for gdb. Since gdb is not yet running on
>  > +  * MPE and I think that gcc_plt_call will need an MPE variant, use
>  > +  * the following in lieu of the DO_GLOBAL_DTORS_BODY declared in pa.h
>  > +  */
>What you'll need to do to find out is determine whether or not your runtime
>linker allows a return location from a call to be a stack address.

If you mean "does MPE allow the ability to execute code in the data stack?",
then, no. When I did the Java JIT for MPE for HP this was a major stumbling
area as MPE requires code to be in code pages, not data pages. The stack
area are all marked as data pages. I had to write some exotic kernel stuff
to create a code page that still got mapped into SR5 space to make the JIT
work. I suppose I can use the same techniques here. (I'll worry about that
when I get to the gdb port).

>  > + #undef  ASM_DECLARE_FUNCTION_NAME
>  > + #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
[snip]
>If the only difference is that you need a PRIV_LEV=3 on a static function, I
>see no reason we can't promote that into som.h.  I believe that would
>eliminate the need for a separate ASM_DECLARE_FUNCTION_NAME, right?

I would prefer this route too. BTW - you mean pa.h, don't you? :-)

>If you end up with a separate ASM_DECLARE_FUNCTION_NAME you certainly do
>not need TARGET_PORTABLE_RUNTIME support ;-)

Actually, MPE doesn't need it anyway.

>  > + #undef ASM_IDENTIFY_GCC
>  > + #define ASM_IDENTIFY_GCC(FILE)                                         
>  >         \
>  > +         do {
       \
>  > +                 fputs ("; gcc_compiled.:\n", FILE);
      \
>  > +                 fprintf (FILE, "\t.compiler \"%s %s %s\"\n",
       \
>  > +                         main_input_filename,
       \
>  > +                         "GNU_C_Compiler",
    \
>  > +                         version_string);
   \
>  > +         } while (0)
>Only problem with this is formatting.  I strongly recommend you read the GNU
>coding standards.

>Two space indention for nesting levels please, not tabs, not four spaces, but
>two.  

I seem to have a problem with my mailer and tabs as my version looks correct.
I'll remove the tabs completely.

It may be a couple of days before I'll resubmit as I need to rebuild and test
your suggested changes to the <control Y> stuff (mpebreak.asm).

Also, since you asked (long double) ... I'll also submit pa.c, pa.h and
pa.md. I know these will be more "controversial", but at least we can
begin the discussions.

Regards,


M.
--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--

Re: MPE Port

[Mark Klein]

In message < 4.1.19990906102304.00c72c80@garfield.dis.com >you write:

>> + #undef CPP_PREDEFINES
>> + #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
>> -Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"

>You should move the -D definitions into a CPP_SPEC string to avoid ANSI
>namespace pollution.

Hmmm. I just lifted the HP-UX code and change hp9000s800 to hp3000s900.
I'll change it as you suggest.

>  > + 
>  > + /* HPUX needs gcc_plt_call for gdb. Since gdb is not yet running on
>  > +  * MPE and I think that gcc_plt_call will need an MPE variant, use
>  > +  * the following in lieu of the DO_GLOBAL_DTORS_BODY declared in pa.h
>  > +  */
>What you'll need to do to find out is determine whether or not your runtime
>linker allows a return location from a call to be a stack address.

If you mean "does MPE allow the ability to execute code in the data stack?",
then, no. When I did the Java JIT for MPE for HP this was a major stumbling
area as MPE requires code to be in code pages, not data pages. The stack
area are all marked as data pages. I had to write some exotic kernel stuff
to create a code page that still got mapped into SR5 space to make the JIT
work. I suppose I can use the same techniques here. (I'll worry about that
when I get to the gdb port).

>  > + #undef  ASM_DECLARE_FUNCTION_NAME
>  > + #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
[snip]
>If the only difference is that you need a PRIV_LEV=3 on a static function, I
>see no reason we can't promote that into som.h.  I believe that would
>eliminate the need for a separate ASM_DECLARE_FUNCTION_NAME, right?

I would prefer this route too. BTW - you mean pa.h, don't you? :-)

>If you end up with a separate ASM_DECLARE_FUNCTION_NAME you certainly do
>not need TARGET_PORTABLE_RUNTIME support ;-)

Actually, MPE doesn't need it anyway.

>  > + #undef ASM_IDENTIFY_GCC
>  > + #define ASM_IDENTIFY_GCC(FILE)                                         
>  >         \
>  > +         do {
       \
>  > +                 fputs ("; gcc_compiled.:\n", FILE);
      \
>  > +                 fprintf (FILE, "\t.compiler \"%s %s %s\"\n",
       \
>  > +                         main_input_filename,
       \
>  > +                         "GNU_C_Compiler",
    \
>  > +                         version_string);
   \
>  > +         } while (0)
>Only problem with this is formatting.  I strongly recommend you read the GNU
>coding standards.

>Two space indention for nesting levels please, not tabs, not four spaces, but
>two.  

I seem to have a problem with my mailer and tabs as my version looks correct.
I'll remove the tabs completely.

It may be a couple of days before I'll resubmit as I need to rebuild and test
your suggested changes to the <control Y> stuff (mpebreak.asm).

Also, since you asked (long double) ... I'll also submit pa.c, pa.h and
pa.md. I know these will be more "controversial", but at least we can
begin the discussions.

Regards,


M.
--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--

Re: MPE Port

[Jeffrey A Law]

  In message <4.1.19990907082210.00c21980@garfield.dis.com>you write:
  > In message <4.1.19990906102304.00c72c80@garfield.dis.com>you write:
  > 
  > >> + #undef CPP_PREDEFINES
  > >> + #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
  > >> -Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"
  > 
  > >You should move the -D definitions into a CPP_SPEC string to avoid ANSI
  > >namespace pollution.
  > 
  > Hmmm. I just lifted the HP-UX code and change hp9000s800 to hp3000s900.
  > I'll change it as you suggest.
Thanks.  It would be nice to convert all the old stuff so that people don't
think what those older ports do is actually right ;-)  Time time time.


  > If you mean "does MPE allow the ability to execute code in the data stack?"
  > then, no. When I did the Java JIT for MPE for HP this was a major stumbling
  > area as MPE requires code to be in code pages, not data pages. The stack
  > area are all marked as data pages. I had to write some exotic kernel stuff
  > to create a code page that still got mapped into SR5 space to make the JIT
  > work. I suppose I can use the same techniques here. (I'll worry about that
  > when I get to the gdb port).
So, how does dynamic linking work on MPE?

I believe gdb has some capabilities to build inferior function call
stubs/trampolines in the text space, but it's fragile -- it depends on being
able to find enough space before/after the program to write it's little
stub/trampoline in the text segment.  If you don't have space, then you lose.
I also believe it is the case that few popular systems need this capability
so the code in gdb may have bitrotted.

It sounds like you're going to have to provide a stub of some kind for gdb's
use in inferior calls.  The structure is going to be radically different from
__gcc_plt_call, but the mechanism you use to get it bound into the executable
should probably mirror __gcc_plt_call.


  > 
  > >  > + #undef  ASM_DECLARE_FUNCTION_NAME
  > >  > + #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
  > [snip]
  > >If the only difference is that you need a PRIV_LEV=3 on a static function,
  >  I
  > >see no reason we can't promote that into som.h.  I believe that would
  > >eliminate the need for a separate ASM_DECLARE_FUNCTION_NAME, right?
  > 
  > I would prefer this route too. BTW - you mean pa.h, don't you? :-)
Me too.  Let's just tack on the PRIV_LEV=3 into som.h (yes, things moved :-)
I'll go ahead and do that now ;-)  So you can zap the ASM_DECLARE_FUNCTION_NAME
stuff from your changes.



jeff

Re: MPE Port

[Mark Klein]

At 11:30 PM 10/25/99 -0600, Jeffrey A Law wrote:


>So, how does dynamic linking work on MPE?

There is a table called the XRT (if I understand it correctly on HP-UX, it
is similar in function to the PLT there) that is fixed up at execution time
with the space, offset of the code, and the DP and SP of the called procedure.
There are support routines that can dynamically load a program and create an
XRT for it. All "procedure labels" on MPE are really pointers to the XRT
entry. There are entry and exit stubs to set and restore those registers and
to promote privilege as needed.

Multiple invocations of the program could result in various pieces
being loaded into different spaces on each invocation. There is also the
ability to create procedures that are "option unresolved" in that on some
machines, they can appear and others, they may not. Everything is determined
at run time. (That's why I have such problems with the autoconf on MPE :-)).

>It sounds like you're going to have to provide a stub of some kind for gdb's
>use in inferior calls.  The structure is going to be radically different from
>__gcc_plt_call, but the mechanism you use to get it bound into the executable
>should probably mirror __gcc_plt_call.
I'm getting "pleads" from a bunch of users to complete the gdb port, so I'm 
going
to start looking at this as soon as I have time. I don't know the purpose of a
"trampoline" and what the __gcc_plt_call does, yet. Can you enlighten me?

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991026065301.00c68310@garfield.dis.com >you write:

  > There is a table called the XRT (if I understand it correctly on HP-UX, it
  > is similar in function to the PLT there) that is fixed up at execution time
  > with the space, offset of the code, and the DP and SP of the called
  > procedure.
  > There are support routines that can dynamically load a program and create
  > an XRT for it. All "procedure labels" on MPE are really pointers to the XRT
  > entry. There are entry and exit stubs to set and restore those registers
  > and to promote privilege as needed.
Not exactly what I was looking for.

I'm interested in how/where are dynamic libraries loaded, does the dynamic
linker make a distinction between code & data in the dynamic library, if
so, does it arrange to load them in different spaces (which would be a
significant divergence from the hpux dynamic linker).


More along the lines of how does mapping of dynamic executables work.  THe


  > to start looking at this as soon as I have time. I don't know the purpose
  > of a "trampoline" and what the __gcc_plt_call does, yet. Can you
  > enlighten me?
You'd have to read the gdb code for all the grody details.

When gdb wants to call a function in the inferior program, it writes a bunch of
code onto the stack (ie the stub/trampoline) which is responsible for doing
argument setup, dealing with cross space calls/returns, etc etc.).  It then
transfers execution control to that code on the stack, which in turn calls
the final target.

__gcc_plt_call is necessary because the hpux dynamic linker will not allow
the return address for a call to be in a non-text, non-shlib space when the
target function is lazily bound.
jeff

Re: MPE Port

[Mark Klein]

At 08:01 PM 10/26/99 -0600, Jeffrey A Law wrote:

>I'm interested in how/where are dynamic libraries loaded, does the dynamic
>linker make a distinction between code & data in the dynamic library, if
>so, does it arrange to load them in different spaces (which would be a
>significant divergence from the hpux dynamic linker).

Aha.

The short answer is "yes" - data and code are loaded into separate spaces
and the XRT is constructed at load time to point to the space as well as
the offset of each routine that will be referenced in a "shared" library.

[The long answer follows]

But, once a library is loaded by the first reference, all other users will
reference the same code space (it won't be different between concurrent,
but it could be different between separate invocations of the same
program if the program isn't concurrently accessed).

Code lives in SR4 space, and SR4 will change based on the library
where the code lives. The initial program exists in one space. Each
loaded library lives in its own space, and the entry and exit stubs
are responsible for setting SR4.

Here is a sample stack trace for a printf():

$1e ($60) nmdebug > tr,d,i
        PC=a.00ef5264 FWRITE
NM* 0) SP=41855830 RP=a.00ef5230 ?FWRITE+$8
          export stub: 16c.003f6cf4 _process_output+$e0
NM  1) SP=41855830 RP=16c.003f6fc4 _px_write+$1c8
NM  2) SP=41855770 RP=16c.003f6de8 ?_px_write+$8
          export stub: 2c5.00012c60 write+$20
NM  3) SP=418556b0 RP=2c5.0000d8f0 _xflsbuf+$a4
NM  4) SP=41855670 RP=2c5.0000c1f8 _doprnt+$274
NM  5) SP=41855630 RP=2c5.0000af20 printf+$44
NM  6) SP=418536b0 RP=2c5.0000abe8 main+$28
NM  7) SP=41853670 RP=2c5.00000000
      (end of NM stack)
$1f ($60) nmdebug >

The main program is in space 0x2c5, the shared library containing _px_write()
is 0x16c, and finally FWRITE is in space 0xa. The ?FWRITE entry is a stub that
makes sure SR4 is correct:

$21 ($60) nmdebug > dc ?FWRITE+8,7
SYS $a.ef5230
00ef5230  ?FWRITE+$8      4bd53fc9  LDW      -28(0,30),21
00ef5234  ?FWRITE+$c      4bc23fd1  LDW      -24(0,30),2
00ef5238  ?FWRITE+$10     00153820  MTSP     21,4
00ef523c  ?FWRITE+$14     e0402000  BE       0(4,2)
00ef5240  ?FWRITE+$18     4bdb3fc1  LDW      -32(0,30),27


>__gcc_plt_call is necessary because the hpux dynamic linker will not allow
>the return address for a call to be in a non-text, non-shlib space when the
>target function is lazily bound.

Looks like I'm going to face the same problem we did when porting Sun's JIT
to MPE because code must be in a page specifically marked as a code page and
not in a data page. I will need an MPE variation of __gcc_plt_call. This
may be problemmatical because MPE also uses multiple privilege rings and
this code will at least have to be at ring 2. OK ... I'll face that hurdle
when the time comes.

Thanks!
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 08:01 PM 10/26/99 -0600, Jeffrey A Law wrote:

>I'm interested in how/where are dynamic libraries loaded, does the dynamic
>linker make a distinction between code & data in the dynamic library, if
>so, does it arrange to load them in different spaces (which would be a
>significant divergence from the hpux dynamic linker).

Aha.

The short answer is "yes" - data and code are loaded into separate spaces
and the XRT is constructed at load time to point to the space as well as
the offset of each routine that will be referenced in a "shared" library.

[The long answer follows]

But, once a library is loaded by the first reference, all other users will
reference the same code space (it won't be different between concurrent,
but it could be different between separate invocations of the same
program if the program isn't concurrently accessed).

Code lives in SR4 space, and SR4 will change based on the library
where the code lives. The initial program exists in one space. Each
loaded library lives in its own space, and the entry and exit stubs
are responsible for setting SR4.

Here is a sample stack trace for a printf():

$1e ($60) nmdebug > tr,d,i
        PC=a.00ef5264 FWRITE
NM* 0) SP=41855830 RP=a.00ef5230 ?FWRITE+$8
          export stub: 16c.003f6cf4 _process_output+$e0
NM  1) SP=41855830 RP=16c.003f6fc4 _px_write+$1c8
NM  2) SP=41855770 RP=16c.003f6de8 ?_px_write+$8
          export stub: 2c5.00012c60 write+$20
NM  3) SP=418556b0 RP=2c5.0000d8f0 _xflsbuf+$a4
NM  4) SP=41855670 RP=2c5.0000c1f8 _doprnt+$274
NM  5) SP=41855630 RP=2c5.0000af20 printf+$44
NM  6) SP=418536b0 RP=2c5.0000abe8 main+$28
NM  7) SP=41853670 RP=2c5.00000000
      (end of NM stack)
$1f ($60) nmdebug >

The main program is in space 0x2c5, the shared library containing _px_write()
is 0x16c, and finally FWRITE is in space 0xa. The ?FWRITE entry is a stub that
makes sure SR4 is correct:

$21 ($60) nmdebug > dc ?FWRITE+8,7
SYS $a.ef5230
00ef5230  ?FWRITE+$8      4bd53fc9  LDW      -28(0,30),21
00ef5234  ?FWRITE+$c      4bc23fd1  LDW      -24(0,30),2
00ef5238  ?FWRITE+$10     00153820  MTSP     21,4
00ef523c  ?FWRITE+$14     e0402000  BE       0(4,2)
00ef5240  ?FWRITE+$18     4bdb3fc1  LDW      -32(0,30),27


>__gcc_plt_call is necessary because the hpux dynamic linker will not allow
>the return address for a call to be in a non-text, non-shlib space when the
>target function is lazily bound.

Looks like I'm going to face the same problem we did when porting Sun's JIT
to MPE because code must be in a page specifically marked as a code page and
not in a data page. I will need an MPE variation of __gcc_plt_call. This
may be problemmatical because MPE also uses multiple privilege rings and
this code will at least have to be at ring 2. OK ... I'll face that hurdle
when the time comes.

Thanks!
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991026065301.00c68310@garfield.dis.com >you write:

  > There is a table called the XRT (if I understand it correctly on HP-UX, it
  > is similar in function to the PLT there) that is fixed up at execution time
  > with the space, offset of the code, and the DP and SP of the called
  > procedure.
  > There are support routines that can dynamically load a program and create
  > an XRT for it. All "procedure labels" on MPE are really pointers to the XRT
  > entry. There are entry and exit stubs to set and restore those registers
  > and to promote privilege as needed.
Not exactly what I was looking for.

I'm interested in how/where are dynamic libraries loaded, does the dynamic
linker make a distinction between code & data in the dynamic library, if
so, does it arrange to load them in different spaces (which would be a
significant divergence from the hpux dynamic linker).


More along the lines of how does mapping of dynamic executables work.  THe


  > to start looking at this as soon as I have time. I don't know the purpose
  > of a "trampoline" and what the __gcc_plt_call does, yet. Can you
  > enlighten me?
You'd have to read the gdb code for all the grody details.

When gdb wants to call a function in the inferior program, it writes a bunch of
code onto the stack (ie the stub/trampoline) which is responsible for doing
argument setup, dealing with cross space calls/returns, etc etc.).  It then
transfers execution control to that code on the stack, which in turn calls
the final target.

__gcc_plt_call is necessary because the hpux dynamic linker will not allow
the return address for a call to be in a non-text, non-shlib space when the
target function is lazily bound.
jeff

Re: MPE Port

[Mark Klein]

At 11:30 PM 10/25/99 -0600, Jeffrey A Law wrote:


>So, how does dynamic linking work on MPE?

There is a table called the XRT (if I understand it correctly on HP-UX, it
is similar in function to the PLT there) that is fixed up at execution time
with the space, offset of the code, and the DP and SP of the called procedure.
There are support routines that can dynamically load a program and create an
XRT for it. All "procedure labels" on MPE are really pointers to the XRT
entry. There are entry and exit stubs to set and restore those registers and
to promote privilege as needed.

Multiple invocations of the program could result in various pieces
being loaded into different spaces on each invocation. There is also the
ability to create procedures that are "option unresolved" in that on some
machines, they can appear and others, they may not. Everything is determined
at run time. (That's why I have such problems with the autoconf on MPE :-)).

>It sounds like you're going to have to provide a stub of some kind for gdb's
>use in inferior calls.  The structure is going to be radically different from
>__gcc_plt_call, but the mechanism you use to get it bound into the executable
>should probably mirror __gcc_plt_call.
I'm getting "pleads" from a bunch of users to complete the gdb port, so I'm 
going
to start looking at this as soon as I have time. I don't know the purpose of a
"trampoline" and what the __gcc_plt_call does, yet. Can you enlighten me?

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message <4.1.19990907082210.00c21980@garfield.dis.com>you write:
  > In message <4.1.19990906102304.00c72c80@garfield.dis.com>you write:
  > 
  > >> + #undef CPP_PREDEFINES
  > >> + #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
  > >> -Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"
  > 
  > >You should move the -D definitions into a CPP_SPEC string to avoid ANSI
  > >namespace pollution.
  > 
  > Hmmm. I just lifted the HP-UX code and change hp9000s800 to hp3000s900.
  > I'll change it as you suggest.
Thanks.  It would be nice to convert all the old stuff so that people don't
think what those older ports do is actually right ;-)  Time time time.


  > If you mean "does MPE allow the ability to execute code in the data stack?"
  > then, no. When I did the Java JIT for MPE for HP this was a major stumbling
  > area as MPE requires code to be in code pages, not data pages. The stack
  > area are all marked as data pages. I had to write some exotic kernel stuff
  > to create a code page that still got mapped into SR5 space to make the JIT
  > work. I suppose I can use the same techniques here. (I'll worry about that
  > when I get to the gdb port).
So, how does dynamic linking work on MPE?

I believe gdb has some capabilities to build inferior function call
stubs/trampolines in the text space, but it's fragile -- it depends on being
able to find enough space before/after the program to write it's little
stub/trampoline in the text segment.  If you don't have space, then you lose.
I also believe it is the case that few popular systems need this capability
so the code in gdb may have bitrotted.

It sounds like you're going to have to provide a stub of some kind for gdb's
use in inferior calls.  The structure is going to be radically different from
__gcc_plt_call, but the mechanism you use to get it bound into the executable
should probably mirror __gcc_plt_call.


  > 
  > >  > + #undef  ASM_DECLARE_FUNCTION_NAME
  > >  > + #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
  > [snip]
  > >If the only difference is that you need a PRIV_LEV=3 on a static function,
  >  I
  > >see no reason we can't promote that into som.h.  I believe that would
  > >eliminate the need for a separate ASM_DECLARE_FUNCTION_NAME, right?
  > 
  > I would prefer this route too. BTW - you mean pa.h, don't you? :-)
Me too.  Let's just tack on the PRIV_LEV=3 into som.h (yes, things moved :-)
I'll go ahead and do that now ;-)  So you can zap the ASM_DECLARE_FUNCTION_NAME
stuff from your changes.



jeff

Re: MPE Port

[Mark Klein]

Explanation:

I'm not sure where this should go, but ...

HP tar (more correctly, MKS tar) has bugs such that it will report that
it failed, even if successful. This install wrapper is to work around 
that and allow a complete installation without being handheld.


Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * install.mpe: New file for MPE port.

diff -c -N -r -x CVS -x Entries -x Repository -x Root -x . egcs/install.mpe
egcs-ss/install.mpe
*** egcs/install.mpe	Wed Dec 31 16:00:00 1969
--- egcs-ss/install.mpe	Mon Aug 30 21:52:57 1999
***************
*** 0 ****
--- 1,17 ----
+ dirs="gcc etc hppa1.0-hp-mpeix/* texinfo"
+ for d in $dirs; do
+     if [ $d = gcc ] ; then
+ 	(echo Installing gcc;				\
+ 		cd gcc; 				\
+ 		make 	install-common install-libgcc	\
+ 			install-man lang.install-normal	\
+ 			install-driver;			\
+ 		make	TAROUTOPTS=xopvf install-headers\
+ 	)
+     else
+ 	(echo Installing $d;				\
+ 		cd $d;					\
+ 		make install				\
+ 	)
+     fi
+ done

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906103545.00c8b9a0@garfield.dis.com >you write:
  > Explanation:
  > 
  > I'm not sure where this should go, but ...
  > 
  > HP tar (more correctly, MKS tar) has bugs such that it will report that
  > it failed, even if successful. This install wrapper is to work around 
  > that and allow a complete installation without being handheld.
By chance do you have a functional cpio?

If so you can change gcc/configure.in to use install-headers-cpio to switch to
cpio instead of tar.


jeff

Re: MPE Port

[Mark Klein]

At 02:36 AM 9/8/99 -0600, Jeffrey A Law wrote:

>By chance do you have a functional cpio?
>
>If so you can change gcc/configure.in to use install-headers-cpio to switch to
>cpio instead of tar.

Yes, but it suffered from the same problem. (I think MKS is using shared source
for both tar and cpio). The problem is that it tries to store/copy . and .. and
that results in a "duplicate" in the destination and ends with an error. I
started to look at porting GNU tar, but there are file characteristics (meta
data) that needs to get "attached" to each file, and I wasn't sure how to
do that. I've figured out what HP tar does and may be able to extend GNU
tar to do the same ... but still haven't tried it.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990908063104.00c24100@garfield.dis.com >you write:
  > Yes, but it suffered from the same problem. (I think MKS is using shared
  > source for both tar and cpio). The problem is that it tries to store/copy
  > . and ..  and that results in a "duplicate" in the destination and ends
  >  with an error. I started to look at porting GNU tar, but there are file
  > characteristics (meta data) that needs to get "attached" to each file,
  > and I wasn't sure how to do that. I've figured out what HP tar does and
  > may be able to extend GNU tar to do the same ... but still haven't tried
  > it.
Ugh.

Presumably there's little chance of getting HP to fix their braindead tools?

If we indeed to have to work around the braindead tar, we may be able to do 
so in a cleaner fashion.

It seems to me the only issue is that tar is crapping out early with an error
and that you could create a new make rule for your braindead tar in your x-*
fragment file, then set up configure.in to use it.

It would model the existing install-headers-tar fragment closely, except that
it would ignore errors from tar.

jeff

Re: MPE Port

[Mark Klein]

At 06:39 AM 9/13/99 -0600, Jeffrey A Law wrote:

>Ugh.
>
>Presumably there's little chance of getting HP to fix their braindead tools?

Were it so easy ... if they add the ability to do so, I would've done it
a long time ago. Unfortunately, these tools were licensed from MKS and
they maintain complete control over the source.

>It seems to me the only issue is that tar is crapping out early with an error
>and that you could create a new make rule for your braindead tar in your x-*
>fragment file, then set up configure.in to use it.
>
>It would model the existing install-headers-tar fragment closely, except that
>it would ignore errors from tar.

I'll give that a try and let you know.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 06:39 AM 9/13/99 -0600, Jeffrey A Law wrote:

>Ugh.
>
>Presumably there's little chance of getting HP to fix their braindead tools?

Were it so easy ... if they add the ability to do so, I would've done it
a long time ago. Unfortunately, these tools were licensed from MKS and
they maintain complete control over the source.

>It seems to me the only issue is that tar is crapping out early with an error
>and that you could create a new make rule for your braindead tar in your x-*
>fragment file, then set up configure.in to use it.
>
>It would model the existing install-headers-tar fragment closely, except that
>it would ignore errors from tar.

I'll give that a try and let you know.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990908063104.00c24100@garfield.dis.com >you write:
  > Yes, but it suffered from the same problem. (I think MKS is using shared
  > source for both tar and cpio). The problem is that it tries to store/copy
  > . and ..  and that results in a "duplicate" in the destination and ends
  >  with an error. I started to look at porting GNU tar, but there are file
  > characteristics (meta data) that needs to get "attached" to each file,
  > and I wasn't sure how to do that. I've figured out what HP tar does and
  > may be able to extend GNU tar to do the same ... but still haven't tried
  > it.
Ugh.

Presumably there's little chance of getting HP to fix their braindead tools?

If we indeed to have to work around the braindead tar, we may be able to do 
so in a cleaner fashion.

It seems to me the only issue is that tar is crapping out early with an error
and that you could create a new make rule for your braindead tar in your x-*
fragment file, then set up configure.in to use it.

It would model the existing install-headers-tar fragment closely, except that
it would ignore errors from tar.

jeff

Re: MPE Port

[Mark Klein]

At 02:36 AM 9/8/99 -0600, Jeffrey A Law wrote:

>By chance do you have a functional cpio?
>
>If so you can change gcc/configure.in to use install-headers-cpio to switch to
>cpio instead of tar.

Yes, but it suffered from the same problem. (I think MKS is using shared source
for both tar and cpio). The problem is that it tries to store/copy . and .. and
that results in a "duplicate" in the destination and ends with an error. I
started to look at porting GNU tar, but there are file characteristics (meta
data) that needs to get "attached" to each file, and I wasn't sure how to
do that. I've figured out what HP tar does and may be able to extend GNU
tar to do the same ... but still haven't tried it.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906103545.00c8b9a0@garfield.dis.com >you write:
  > Explanation:
  > 
  > I'm not sure where this should go, but ...
  > 
  > HP tar (more correctly, MKS tar) has bugs such that it will report that
  > it failed, even if successful. This install wrapper is to work around 
  > that and allow a complete installation without being handheld.
By chance do you have a functional cpio?

If so you can change gcc/configure.in to use install-headers-cpio to switch to
cpio instead of tar.


jeff

Re: MPE Port

[Mark Klein]

Explanation:

I'm not sure where this should go, but ...

HP tar (more correctly, MKS tar) has bugs such that it will report that
it failed, even if successful. This install wrapper is to work around 
that and allow a complete installation without being handheld.


Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * install.mpe: New file for MPE port.

diff -c -N -r -x CVS -x Entries -x Repository -x Root -x . egcs/install.mpe
egcs-ss/install.mpe
*** egcs/install.mpe	Wed Dec 31 16:00:00 1969
--- egcs-ss/install.mpe	Mon Aug 30 21:52:57 1999
***************
*** 0 ****
--- 1,17 ----
+ dirs="gcc etc hppa1.0-hp-mpeix/* texinfo"
+ for d in $dirs; do
+     if [ $d = gcc ] ; then
+ 	(echo Installing gcc;				\
+ 		cd gcc; 				\
+ 		make 	install-common install-libgcc	\
+ 			install-man lang.install-normal	\
+ 			install-driver;			\
+ 		make	TAROUTOPTS=xopvf install-headers\
+ 	)
+     else
+ 	(echo Installing $d;				\
+ 		cd $d;					\
+ 		make install				\
+ 	)
+     fi
+ done

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * libio/configure.in: Add mpeix.mt make fragment.

*** egcs/libio/configure.in	Mon Aug 30 21:50:49 1999
--- egcs-ss/libio/configure.in	Mon Aug 30 21:53:00 1999
***************
*** 49,54 ****
--- 49,55 ----
  frags=
  
  case "${target}" in
+   *-mpeix*)      frags="mpeix.mt" ;;
    *-hpux*)       frags=hpux.mt ;;
    alpha*-*-linux-gnulibc1)
  		 frags="linux.mt linuxaxp1.mt mtsafe.mt" ;;

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906102710.00c76710@garfield.dis.com >you write:
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * libio/configure.in: Add mpeix.mt make fragment.
  > 
  > *** egcs/libio/configure.in	Mon Aug 30 21:50:49 1999
  > --- egcs-ss/libio/configure.in	Mon Aug 30 21:53:00 1999
  > ***************
  > *** 49,54 ****
  > --- 49,55 ----
  >   frags=
  >   
  >   case "${target}" in
  > +   *-mpeix*)      frags="mpeix.mt" ;;
  >     *-hpux*)       frags=hpux.mt ;;
  >     alpha*-*-linux-gnulibc1)
  >   		 frags="linux.mt linuxaxp1.mt mtsafe.mt" ;;
Can you send me the mpeix.mt fragment too? :-)

jeffv

Re: MPE Port

[Mark Klein]

At 02:38 AM 9/8/99 -0600, Jeffrey A Law wrote:


>Can you send me the mpeix.mt fragment too? :-)

Will do ... that's my "punt" and it isn't quite yet working. Still
want it now of after I fix it?

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 02:38 AM 9/8/99 -0600, Jeffrey A Law wrote:


>Can you send me the mpeix.mt fragment too? :-)

Will do ... that's my "punt" and it isn't quite yet working. Still
want it now of after I fix it?

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906102710.00c76710@garfield.dis.com >you write:
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * libio/configure.in: Add mpeix.mt make fragment.
  > 
  > *** egcs/libio/configure.in	Mon Aug 30 21:50:49 1999
  > --- egcs-ss/libio/configure.in	Mon Aug 30 21:53:00 1999
  > ***************
  > *** 49,54 ****
  > --- 49,55 ----
  >   frags=
  >   
  >   case "${target}" in
  > +   *-mpeix*)      frags="mpeix.mt" ;;
  >     *-hpux*)       frags=hpux.mt ;;
  >     alpha*-*-linux-gnulibc1)
  >   		 frags="linux.mt linuxaxp1.mt mtsafe.mt" ;;
Can you send me the mpeix.mt fragment too? :-)

jeffv

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * libio/configure.in: Add mpeix.mt make fragment.

*** egcs/libio/configure.in	Mon Aug 30 21:50:49 1999
--- egcs-ss/libio/configure.in	Mon Aug 30 21:53:00 1999
***************
*** 49,54 ****
--- 49,55 ----
  frags=
  
  case "${target}" in
+   *-mpeix*)      frags="mpeix.mt" ;;
    *-hpux*)       frags=hpux.mt ;;
    alpha*-*-linux-gnulibc1)
  		 frags="linux.mt linuxaxp1.mt mtsafe.mt" ;;

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * README.mpe: Special Instructions for MPE.

*** egcs/README.mpe	Wed Dec 31 16:00:00 1969
--- egcs-ss/README.mpe	Mon Aug 30 21:51:54 1999
***************
*** 0 ****
--- 1,26 ----
+ In order to build gcc under MPE, you will need to do the following:
+ 
+ Install MPE/iX 6.0 or obtain the MPEJXQ1B and PXJXQ1B patches from  
+ HP. You will also need to obtain /usr/contrib/include as it contains
+ certain header files not originally distributed with MPE. The JXQ1
+ patches allow certain special characters not defined in the POSIX
+ specs as part of a pathname. These are standard in MPE/iX 6.0.
+ 
+ Obtain the binary distribution of the GNU Freeware tools from
+ http://jazz.external.hp.com and install them. This is necessary
+ and you will not be able to bootstrap with the HP/C compiler alone.
+ You must minimally install GNUCORE and GNUGCC.
+ 
+ You will also need Perl from http://www.cccd.edu/~markb (also
+ linked to from Jazz). Once perl and at least the GNU Core have  
+ been installed, run the configure script for MPE:
+ 
+ ./configure.mpe
+ 
+ When this completes, cd into obj-MPE and make everything with:  
+ 
+ make
+ 
+ There are some problems with doing a complete automated installation
+ due to bugs in some of HP's tools. Instead of doing a make install
+ from the top level, I would suggest that you ./install.mpe.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906103446.00c85180@garfield.dis.com >you write:
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * README.mpe: Special Instructions for MPE.
Instead of (yet another) README, why not put the install documentation into
the online installation guide?  That's where it belongs.

jeff

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906103446.00c85180@garfield.dis.com >you write:
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * README.mpe: Special Instructions for MPE.
Instead of (yet another) README, why not put the install documentation into
the online installation guide?  That's where it belongs.

jeff

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * README.mpe: Special Instructions for MPE.

*** egcs/README.mpe	Wed Dec 31 16:00:00 1969
--- egcs-ss/README.mpe	Mon Aug 30 21:51:54 1999
***************
*** 0 ****
--- 1,26 ----
+ In order to build gcc under MPE, you will need to do the following:
+ 
+ Install MPE/iX 6.0 or obtain the MPEJXQ1B and PXJXQ1B patches from  
+ HP. You will also need to obtain /usr/contrib/include as it contains
+ certain header files not originally distributed with MPE. The JXQ1
+ patches allow certain special characters not defined in the POSIX
+ specs as part of a pathname. These are standard in MPE/iX 6.0.
+ 
+ Obtain the binary distribution of the GNU Freeware tools from
+ http://jazz.external.hp.com and install them. This is necessary
+ and you will not be able to bootstrap with the HP/C compiler alone.
+ You must minimally install GNUCORE and GNUGCC.
+ 
+ You will also need Perl from http://www.cccd.edu/~markb (also
+ linked to from Jazz). Once perl and at least the GNU Core have  
+ been installed, run the configure script for MPE:
+ 
+ ./configure.mpe
+ 
+ When this completes, cd into obj-MPE and make everything with:  
+ 
+ make
+ 
+ There are some problems with doing a complete automated installation
+ due to bugs in some of HP's tools. Instead of doing a make install
+ from the top level, I would suggest that you ./install.mpe.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * pa/x-pa-mpeix: New file for the MPE port.

*** egcs/gcc/config/pa/x-pa-mpeix	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/x-pa-mpeix	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,17 ----
+ ALLOCA=alloca.o
+ X_CFLAGS=-I/usr/contrib/include -DSYSV -D_POSIX_SOURCE -D_SOCKET_SOURCE
-D_MPEIX_SOURCE -DPOSIX -D_MPEXL_SOURCE
+ CC=gcc
+ AR=/bin/ar
+ OLDAR_FLAGS=rc
+ OLDAR=/bin/ar
+ OLDCC=c89
+ TARGET_LIBGCC2_CFLAGS=
+ LIB2FUNCS_EXTRA= mpebreak.asm quadlib.asm
+ 
+ mpebreak.asm: $(srcdir)/config/pa/mpebreak.asm
+ 	rm -f mpebreak.asm
+ 	cp $(srcdir)/config/pa/mpebreak.asm .
+ 
+ quadlib.asm: $(srcdir)/config/pa/quadlib.asm
+ 	rm -f quadlib.asm
+ 	cp $(srcdir)/config/pa/quadlib.asm .

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * pa/x-pa-mpeix: New file for the MPE port.

*** egcs/gcc/config/pa/x-pa-mpeix	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/x-pa-mpeix	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,17 ----
+ ALLOCA=alloca.o
+ X_CFLAGS=-I/usr/contrib/include -DSYSV -D_POSIX_SOURCE -D_SOCKET_SOURCE
-D_MPEIX_SOURCE -DPOSIX -D_MPEXL_SOURCE
+ CC=gcc
+ AR=/bin/ar
+ OLDAR_FLAGS=rc
+ OLDAR=/bin/ar
+ OLDCC=c89
+ TARGET_LIBGCC2_CFLAGS=
+ LIB2FUNCS_EXTRA= mpebreak.asm quadlib.asm
+ 
+ mpebreak.asm: $(srcdir)/config/pa/mpebreak.asm
+ 	rm -f mpebreak.asm
+ 	cp $(srcdir)/config/pa/mpebreak.asm .
+ 
+ quadlib.asm: $(srcdir)/config/pa/quadlib.asm
+ 	rm -f quadlib.asm
+ 	cp $(srcdir)/config/pa/quadlib.asm .

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Explanation:

MPE does not use <control C> for interrupts but uses <control Y> 
instead. This is a kludge to allow <control Y> to have the same
semantics as a <control C>. It is done by installing a signal
handler in each program as part of the startup.


Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com>

        * pa/mpebreak.asm: New file for MPE port.

*** egcs/gcc/config/pa/mpebreak.asm	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/mpebreak.asm	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,87 ----
+ ;  Subroutines to arm <control Y> trap handler on MPEiX.
+ ;  Copyright (C) 1999 Free Software Foundation, Inc.
+ 
+ ;  This file is part of GNU CC.
+ 
+ ;  GNU CC is free software; you can redistribute it and/or modify
+ ;  it under the terms of the GNU General Public License as published by
+ ;  the Free Software Foundation; either version 2, or (at your option)
+ ;  any later version.
+ 
+ ;  GNU CC is distributed in the hope that it will be useful,
+ ;  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ ;  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ ;  GNU General Public License for more details.
+ 
+ ; In addition to the permissions in the GNU General Public License, the
+ ; Free Software Foundation gives you unlimited permission to link the
+ ; compiled version of this file with other programs, and to distribute
+ ; those programs without any restriction coming from the use of this
+ ; file.  (The General Public License restrictions do apply in other
+ ; respects; for example, they cover modification of the file, and
+ ; distribution when not linked into another program.)
+ 
+ ;  You should have received a copy of the GNU General Public License
+ ;  along with GNU CC; see the file COPYING.  If not, write to
+ ;  the Free Software Foundation, 59 Temple Place - Suite 330,
+ ;  Boston, MA 02111-1307, USA.
+ 
+ 	.SPACE $PRIVATE$
+ 	.SUBSPA $DATA$,QUAD=1,ALIGN=8,ACCESS=31
+ 	.SUBSPA $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82
+ 	.SPACE $TEXT$
+ 	.SUBSPA $LIT$,QUAD=0,ALIGN=8,ACCESS=44
+ 	.SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
+ 	.IMPORT $global$,DATA
+ 	.IMPORT $$dyncall,MILLICODE
+ 	.compiler "mpebreak.asm GNU_PA-RISC_Assembler 2.8.1"
+ 	.IMPORT XCONTRAP,CODE
+ 	.IMPORT __MPESubsystemBreakHandler,CODE
+ 	.SPACE $PRIVATE$
+ 	.SUBSPA $DATA$
+ 
+ 	.align 4
+ L$C0001
+ 	.word P%__MPESubsystemBreakHandler
+ 	.SPACE $TEXT$
+ 	.SUBSPA $CODE$
+ 
+ 	.align 4
+ 	.EXPORT __MPEArmSubsystemBreak,ENTRY,PRIV_LEV=3
+ __MPEArmSubsystemBreak
+ 	.PROC
+ 	.CALLINFO FRAME=128,CALLS,SAVE_RP
+ 	.ENTRY
+ 	stw %r2,-20(0,%r30)
+ 	ldo 128(%r30),%r30
+ 	addil LR'L$C0001-$global$,%r27
+ 	ldw RR'L$C0001-$global$(%r1),%r26
+ 	.CALL ARGW0=GR,ARGW1=GR
+ 	bl XCONTRAP,%r2
+ 	ldo -120(%r30),%r25
+ 	ldw -148(0,%r30),%r2
+ 	bv 0(%r2)
+ 	ldo -128(%r30),%r30
+ 	.EXIT
+ 	.PROCEND
+ 	.IMPORT RESETCONTROL,CODE
+ 	.IMPORT kill,CODE
+ 	.align 4
+ 	.EXPORT __MPESubsystemBreakHandler,ENTRY,PRIV_LEV=3
+ __MPESubsystemBreakHandler
+ 	.PROC
+ 	.CALLINFO FRAME=128,CALLS,SAVE_RP
+ 	.ENTRY
+ 	stw %r2,-20(0,%r30)
+ 	.CALL 
+ 	bl RESETCONTROL,%r2
+ 	ldo 128(%r30),%r30
+ 	ldi 0,%r26
+ 	.CALL ARGW0=GR,ARGW1=GR
+ 	bl kill,%r2
+ 	ldi 2,%r25
+ 	ldw -148(0,%r30),%r2
+ 	bv 0(%r2)
+ 	ldo -128(%r30),%r30
+ 	.EXIT
+ 	.PROCEND

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906101852.00c6e850@garfield.dis.com >you write:
  > Explanation:
  > 
  > MPE does not use <control C> for interrupts but uses <control Y> 
  > instead. This is a kludge to allow <control Y> to have the same
  > semantics as a <control C>. It is done by installing a signal
  > handler in each program as part of the startup.
  > 
  > 
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com>
  > 
  >         * pa/mpebreak.asm: New file for MPE port.
This really doesn't seem like something that belongs in the compiler, but
instead in some kind of OS library that the user optionally requests.

Re: MPE Port

[Mark Klein]

At 03:36 AM 9/7/99 -0600, Jeffrey A Law wrote:

>  > MPE does not use <control C> for interrupts but uses <control Y> 
>  > instead. This is a kludge to allow <control Y> to have the same
>  > semantics as a <control C>. It is done by installing a signal
>  > handler in each program as part of the startup.
>  > 
>  > 
>  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com>
>  > 
>  >         * pa/mpebreak.asm: New file for MPE port.
>This really doesn't seem like something that belongs in the compiler, but
>instead in some kind of OS library that the user optionally requests.

Since GCC's startup is different than the HP compilers (which do similar
initializations prior to invoking main()), I'm not sure semantically how
to do it outside of the compiler/library. Suggestions?
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990907063758.00c27730@garfield.dis.com >you write:
  > >This really doesn't seem like something that belongs in the compiler, but
  > >instead in some kind of OS library that the user optionally requests.
  > 
  > Since GCC's startup is different than the HP compilers (which do similar
  > initializations prior to invoking main()), I'm not sure semantically how
  > to do it outside of the compiler/library. Suggestions?
There's got to be a way to fire routines before main.

For HP's I do *not* recommend using their SOM file initializer scheme, it
is horribly busted.

Instead use the collect method.  It works by scanning your executable for
symbols with magic names.  It collects them together in a list and __main
will arrange for each of the special functions to be called before your
program gets started.

It uses the same mechanism that global ctors/dtors for C++ uses.

jeff

Re: MPE Port

[Mark Klein]

At 01:42 AM 9/8/99 -0600, Jeffrey A Law wrote:

>Instead use the collect method.  It works by scanning your executable for
>symbols with magic names.  It collects them together in a list and __main
>will arrange for each of the special functions to be called before your
>program gets started.
>
>It uses the same mechanism that global ctors/dtors for C++ uses.

I've rewritten the trap initialization as __attribute__ ((constructor)).

I still run into the same issue (which is substantially the same as
what faces the __gcc_plt_call) ... if it isn't referenced from the
program, it won't get bound in for collect to find it. While I chose
to do it in DO_GLOBAL_CTORS_BODY, I could do the same asm stuff in
either DO_GLOBAL_CTORS_BODY or DO_GLOBAL_DTORS_BODY as is done for
_gcc_plt_call. I'm going to choose the latter, because I am already
redefining it to delete the __gcc_plt_call reference. Is that
acceptable? Because of MPE's late binding, I don't see another way.

Regards,



M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990908195434.00b01950@garfield.dis.com >you write:
  > I still run into the same issue (which is substantially the same as
  > what faces the __gcc_plt_call) ... if it isn't referenced from the
  > program, it won't get bound in for collect to find it.
You have to add it (either the .o or .a containing your constructor) to the
program's link line.

collect is supposed to look at all the files on the link line for constructors
and add them to th ctor/dtor list.

jeff

Re: MPE Port

[Mark Klein]

At 03:38 AM 9/13/99 -0600, Jeffrey A Law wrote:

>You have to add it (either the .o or .a containing your constructor) to the
>program's link line.
>
>collect is supposed to look at all the files on the link line for constructors
>and add them to th ctor/dtor list.

OK. I'll try it as a separate module ... my first attempt embedded it into
libgcc.a as a LIB2FUNCS_EXTRA.


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 03:38 AM 9/13/99 -0600, Jeffrey A Law wrote:

>You have to add it (either the .o or .a containing your constructor) to the
>program's link line.
>
>collect is supposed to look at all the files on the link line for constructors
>and add them to th ctor/dtor list.

OK. I'll try it as a separate module ... my first attempt embedded it into
libgcc.a as a LIB2FUNCS_EXTRA.


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990908195434.00b01950@garfield.dis.com >you write:
  > I still run into the same issue (which is substantially the same as
  > what faces the __gcc_plt_call) ... if it isn't referenced from the
  > program, it won't get bound in for collect to find it.
You have to add it (either the .o or .a containing your constructor) to the
program's link line.

collect is supposed to look at all the files on the link line for constructors
and add them to th ctor/dtor list.

jeff

Re: MPE Port

[Mark Klein]

At 03:38 AM 9/13/99 -0600, Jeffrey A Law wrote:
>   In message <4.1.19990908195434.00b01950@garfield.dis.com>you write:
>   > I still run into the same issue (which is substantially the same as
>   > what faces the __gcc_plt_call) ... if it isn't referenced from the
>   > program, it won't get bound in for collect to find it.
>You have to add it (either the .o or .a containing your constructor) to the
>program's link line.
>
>collect is supposed to look at all the files on the link line for constructors
>and add them to th ctor/dtor list.

This appears to work if I specify the .o containing it separately, but if I
include the global constructor in libgcc.a, it isn't resolved unless I make
explicit reference to it a la __gcc_plt_call. Is collect treating libgcc.a
specially?

MPE doesn't use a crt.o or anything like that where I could "hide" this, so
I'm faced with explicitly using a separate .o file for this purpose. Seems
to me it was easier to use the same technique as the reference to 
__gcc_plt_call
in the DO_GLOBAL_DTORS_BODY macro than trying to jump through all these hoops
to make this a global constructor.

Regards,

M.


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991009200725.00c5a100@garfield.dis.com >you write:
  > MPE doesn't use a crt.o or anything like that where I could "hide" this, so
  > I'm faced with explicitly using a separate .o file for this purpose. Seems
  > to me it was easier to use the same technique as the reference to 
  > __gcc_plt_call
  > in the DO_GLOBAL_DTORS_BODY macro than trying to jump through all these hoo
  > ps
  > to make this a global constructor.
No, it is *totally* inappropriate for this behavior to be forced by GCC.  This
has to be done elsewhere.  If that means explicitly adding a .o to the link
line to get this behavior, well, then that's what'll have to happen.

I can't stress enough that it is totally wrong for us to try and do this
within GCC.


jeff

Re: MPE Port

[Mark Klein]

At 04:59 AM 10/14/99 -0600, Jeffrey A Law wrote:
    ^^^^^
Late night, huh? :-)

>I can't stress enough that it is totally wrong for us to try and do this
>within GCC.

I don't see how this is any different than the following code that is
already in GCC:

/* We want __gcc_plt_call to appear in every program built by
    gcc, so we make a reference to it out of __main.
    We use the asm statement to fool the optimizer into not
    removing the dead (but important) initialization of
    REFERENCE.  */

#define DO_GLOBAL_DTORS_BODY                    \
do {                                            \
   extern void __gcc_plt_call ();                \
   void (*reference)() = &__gcc_plt_call;        \
   func_ptr *p;                                  \
   __asm__ ("" : : "r" (reference));             \
   for (p = __DTOR_LIST__ + 1; *p; )             \
     (*p++) ();                                  \
} while (0)

If you change "__gcc_plt_call" to "__MPE_arm_subsystem_break", what's
the rationale for doing one, but not the other?

gcc provides it's own __main and by so doing, eliminates certain
functionality expected by the system __main. Why is it not
appropriate for gcc to replace functionality that it eliminates?


Regards,


M.


--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991014070452.00aecef0@209.60.244.235 >you write:
  > I don't see how this is any different than the following code that is
  > already in GCC:
Yours is changing the program's user observable behavior.

__gcc_plt_call does not change user observable behavior; it merely provides
a stub that the debugger can use to implement inferior function calls.

jeff

Re: MPE Port

[Mark Klein]

At 11:42 AM 10/14/99 -0600, Jeffrey A Law wrote:

>Yours is changing the program's user observable behavior.

I can make the same argument in reverse:

gcc is generating an observable behavior that is different
from what would happen if compiling the same code under HP's
C and using HP's libraries.

OK, I yield. I'll figure out some other way to try to get
mpebreak.o into the link that doesn't require the user to
manually do it. How far "outside of gcc" do you want this?
Is using LINK_SPEC acceptable?




--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--

Re: MPE Port

[Mark Klein]

At 11:42 AM 10/14/99 -0600, Jeffrey A Law wrote:

>Yours is changing the program's user observable behavior.

I can make the same argument in reverse:

gcc is generating an observable behavior that is different
from what would happen if compiling the same code under HP's
C and using HP's libraries.

OK, I yield. I'll figure out some other way to try to get
mpebreak.o into the link that doesn't require the user to
manually do it. How far "outside of gcc" do you want this?
Is using LINK_SPEC acceptable?




--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991014070452.00aecef0@209.60.244.235 >you write:
  > I don't see how this is any different than the following code that is
  > already in GCC:
Yours is changing the program's user observable behavior.

__gcc_plt_call does not change user observable behavior; it merely provides
a stub that the debugger can use to implement inferior function calls.

jeff

Re: MPE Port

[Mark Klein]

At 04:59 AM 10/14/99 -0600, Jeffrey A Law wrote:
    ^^^^^
Late night, huh? :-)

>I can't stress enough that it is totally wrong for us to try and do this
>within GCC.

I don't see how this is any different than the following code that is
already in GCC:

/* We want __gcc_plt_call to appear in every program built by
    gcc, so we make a reference to it out of __main.
    We use the asm statement to fool the optimizer into not
    removing the dead (but important) initialization of
    REFERENCE.  */

#define DO_GLOBAL_DTORS_BODY                    \
do {                                            \
   extern void __gcc_plt_call ();                \
   void (*reference)() = &__gcc_plt_call;        \
   func_ptr *p;                                  \
   __asm__ ("" : : "r" (reference));             \
   for (p = __DTOR_LIST__ + 1; *p; )             \
     (*p++) ();                                  \
} while (0)

If you change "__gcc_plt_call" to "__MPE_arm_subsystem_break", what's
the rationale for doing one, but not the other?

gcc provides it's own __main and by so doing, eliminates certain
functionality expected by the system __main. Why is it not
appropriate for gcc to replace functionality that it eliminates?


Regards,


M.


--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991009200725.00c5a100@garfield.dis.com >you write:
  > MPE doesn't use a crt.o or anything like that where I could "hide" this, so
  > I'm faced with explicitly using a separate .o file for this purpose. Seems
  > to me it was easier to use the same technique as the reference to 
  > __gcc_plt_call
  > in the DO_GLOBAL_DTORS_BODY macro than trying to jump through all these hoo
  > ps
  > to make this a global constructor.
No, it is *totally* inappropriate for this behavior to be forced by GCC.  This
has to be done elsewhere.  If that means explicitly adding a .o to the link
line to get this behavior, well, then that's what'll have to happen.

I can't stress enough that it is totally wrong for us to try and do this
within GCC.


jeff

Re: MPE Port

[Mark Klein]

At 03:38 AM 9/13/99 -0600, Jeffrey A Law wrote:
>   In message <4.1.19990908195434.00b01950@garfield.dis.com>you write:
>   > I still run into the same issue (which is substantially the same as
>   > what faces the __gcc_plt_call) ... if it isn't referenced from the
>   > program, it won't get bound in for collect to find it.
>You have to add it (either the .o or .a containing your constructor) to the
>program's link line.
>
>collect is supposed to look at all the files on the link line for constructors
>and add them to th ctor/dtor list.

This appears to work if I specify the .o containing it separately, but if I
include the global constructor in libgcc.a, it isn't resolved unless I make
explicit reference to it a la __gcc_plt_call. Is collect treating libgcc.a
specially?

MPE doesn't use a crt.o or anything like that where I could "hide" this, so
I'm faced with explicitly using a separate .o file for this purpose. Seems
to me it was easier to use the same technique as the reference to 
__gcc_plt_call
in the DO_GLOBAL_DTORS_BODY macro than trying to jump through all these hoops
to make this a global constructor.

Regards,

M.


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 03:38 AM 9/13/99 -0600, Jeffrey A Law wrote:

>collect is supposed to look at all the files on the link line for constructors
>and add them to th ctor/dtor list.

Why does collect explicitly not add symbols from a shared library to the
constructor/destructor list? How would those constructors/destructors
ever get run on another platform if they were in a shared library or is
there another mechanism in that case?

TIA


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991108193122.00c7c220@garfield.dis.com >you write:
  > At 03:38 AM 9/13/99 -0600, Jeffrey A Law wrote:
  > 
  > >collect is supposed to look at all the files on the link line for construc
  > tors
  > >and add them to th ctor/dtor list.
  > 
  > Why does collect explicitly not add symbols from a shared library to the
  > constructor/destructor list? How would those constructors/destructors
  > ever get run on another platform if they were in a shared library or is
  > there another mechanism in that case?
Because if someone replaced the library, then all the applications linked
against the library would have to be re-linked just in case the list of
ctors/dtors changed.

So instead collect builds and exports a single constructor function for the
entire library.  *that* function should be added to he ctor/dtor list for
the main program.

That way the shared library can be updated and programs linked against the
library do not need to be relinked if the library's initialization requirements
changed.


jeff

Re: MPE Port

[Mark Klein]

At 08:53 PM 11/8/99 -0700, Jeffrey A Law wrote:


>Because if someone replaced the library, then all the applications linked
>against the library would have to be re-linked just in case the list of
>ctors/dtors changed.
Hmmm ... that's a bit different than MPE since the "final link" is really
at load time. We never need to link against a shared library before using
it for precisely the reason above: a version can be updated without requiring
compiles or links elsewhere.

>So instead collect builds and exports a single constructor function for the
>entire library.  *that* function should be added to he ctor/dtor list for
>the main program.

Aha. Then that's what is failing, but I don't see where. Back to the drawing
board.

(One of these days I'm going to have to get gdb ported :-/)

Thanks.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 08:53 PM 11/8/99 -0700, Jeffrey A Law wrote:


>Because if someone replaced the library, then all the applications linked
>against the library would have to be re-linked just in case the list of
>ctors/dtors changed.
Hmmm ... that's a bit different than MPE since the "final link" is really
at load time. We never need to link against a shared library before using
it for precisely the reason above: a version can be updated without requiring
compiles or links elsewhere.

>So instead collect builds and exports a single constructor function for the
>entire library.  *that* function should be added to he ctor/dtor list for
>the main program.

Aha. Then that's what is failing, but I don't see where. Back to the drawing
board.

(One of these days I'm going to have to get gdb ported :-/)

Thanks.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.2.0.58.19991108193122.00c7c220@garfield.dis.com >you write:
  > At 03:38 AM 9/13/99 -0600, Jeffrey A Law wrote:
  > 
  > >collect is supposed to look at all the files on the link line for construc
  > tors
  > >and add them to th ctor/dtor list.
  > 
  > Why does collect explicitly not add symbols from a shared library to the
  > constructor/destructor list? How would those constructors/destructors
  > ever get run on another platform if they were in a shared library or is
  > there another mechanism in that case?
Because if someone replaced the library, then all the applications linked
against the library would have to be re-linked just in case the list of
ctors/dtors changed.

So instead collect builds and exports a single constructor function for the
entire library.  *that* function should be added to he ctor/dtor list for
the main program.

That way the shared library can be updated and programs linked against the
library do not need to be relinked if the library's initialization requirements
changed.


jeff

Re: MPE Port

[Mark Klein]

At 03:38 AM 9/13/99 -0600, Jeffrey A Law wrote:

>collect is supposed to look at all the files on the link line for constructors
>and add them to th ctor/dtor list.

Why does collect explicitly not add symbols from a shared library to the
constructor/destructor list? How would those constructors/destructors
ever get run on another platform if they were in a shared library or is
there another mechanism in that case?

TIA


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 01:42 AM 9/8/99 -0600, Jeffrey A Law wrote:

>Instead use the collect method.  It works by scanning your executable for
>symbols with magic names.  It collects them together in a list and __main
>will arrange for each of the special functions to be called before your
>program gets started.
>
>It uses the same mechanism that global ctors/dtors for C++ uses.

I've rewritten the trap initialization as __attribute__ ((constructor)).

I still run into the same issue (which is substantially the same as
what faces the __gcc_plt_call) ... if it isn't referenced from the
program, it won't get bound in for collect to find it. While I chose
to do it in DO_GLOBAL_CTORS_BODY, I could do the same asm stuff in
either DO_GLOBAL_CTORS_BODY or DO_GLOBAL_DTORS_BODY as is done for
_gcc_plt_call. I'm going to choose the latter, because I am already
redefining it to delete the __gcc_plt_call reference. Is that
acceptable? Because of MPE's late binding, I don't see another way.

Regards,



M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990907063758.00c27730@garfield.dis.com >you write:
  > >This really doesn't seem like something that belongs in the compiler, but
  > >instead in some kind of OS library that the user optionally requests.
  > 
  > Since GCC's startup is different than the HP compilers (which do similar
  > initializations prior to invoking main()), I'm not sure semantically how
  > to do it outside of the compiler/library. Suggestions?
There's got to be a way to fire routines before main.

For HP's I do *not* recommend using their SOM file initializer scheme, it
is horribly busted.

Instead use the collect method.  It works by scanning your executable for
symbols with magic names.  It collects them together in a list and __main
will arrange for each of the special functions to be called before your
program gets started.

It uses the same mechanism that global ctors/dtors for C++ uses.

jeff

Re: MPE Port

[Mark Klein]

At 03:36 AM 9/7/99 -0600, Jeffrey A Law wrote:

>  > MPE does not use <control C> for interrupts but uses <control Y> 
>  > instead. This is a kludge to allow <control Y> to have the same
>  > semantics as a <control C>. It is done by installing a signal
>  > handler in each program as part of the startup.
>  > 
>  > 
>  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com>
>  > 
>  >         * pa/mpebreak.asm: New file for MPE port.
>This really doesn't seem like something that belongs in the compiler, but
>instead in some kind of OS library that the user optionally requests.

Since GCC's startup is different than the HP compilers (which do similar
initializations prior to invoking main()), I'm not sure semantically how
to do it outside of the compiler/library. Suggestions?
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906101852.00c6e850@garfield.dis.com >you write:
  > Explanation:
  > 
  > MPE does not use <control C> for interrupts but uses <control Y> 
  > instead. This is a kludge to allow <control Y> to have the same
  > semantics as a <control C>. It is done by installing a signal
  > handler in each program as part of the startup.
  > 
  > 
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com>
  > 
  >         * pa/mpebreak.asm: New file for MPE port.
This really doesn't seem like something that belongs in the compiler, but
instead in some kind of OS library that the user optionally requests.

Re: MPE Port

[Mark Klein]

Explanation:

MPE does not use <control C> for interrupts but uses <control Y> 
instead. This is a kludge to allow <control Y> to have the same
semantics as a <control C>. It is done by installing a signal
handler in each program as part of the startup.


Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com>

        * pa/mpebreak.asm: New file for MPE port.

*** egcs/gcc/config/pa/mpebreak.asm	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/mpebreak.asm	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,87 ----
+ ;  Subroutines to arm <control Y> trap handler on MPEiX.
+ ;  Copyright (C) 1999 Free Software Foundation, Inc.
+ 
+ ;  This file is part of GNU CC.
+ 
+ ;  GNU CC is free software; you can redistribute it and/or modify
+ ;  it under the terms of the GNU General Public License as published by
+ ;  the Free Software Foundation; either version 2, or (at your option)
+ ;  any later version.
+ 
+ ;  GNU CC is distributed in the hope that it will be useful,
+ ;  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ ;  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ ;  GNU General Public License for more details.
+ 
+ ; In addition to the permissions in the GNU General Public License, the
+ ; Free Software Foundation gives you unlimited permission to link the
+ ; compiled version of this file with other programs, and to distribute
+ ; those programs without any restriction coming from the use of this
+ ; file.  (The General Public License restrictions do apply in other
+ ; respects; for example, they cover modification of the file, and
+ ; distribution when not linked into another program.)
+ 
+ ;  You should have received a copy of the GNU General Public License
+ ;  along with GNU CC; see the file COPYING.  If not, write to
+ ;  the Free Software Foundation, 59 Temple Place - Suite 330,
+ ;  Boston, MA 02111-1307, USA.
+ 
+ 	.SPACE $PRIVATE$
+ 	.SUBSPA $DATA$,QUAD=1,ALIGN=8,ACCESS=31
+ 	.SUBSPA $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82
+ 	.SPACE $TEXT$
+ 	.SUBSPA $LIT$,QUAD=0,ALIGN=8,ACCESS=44
+ 	.SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
+ 	.IMPORT $global$,DATA
+ 	.IMPORT $$dyncall,MILLICODE
+ 	.compiler "mpebreak.asm GNU_PA-RISC_Assembler 2.8.1"
+ 	.IMPORT XCONTRAP,CODE
+ 	.IMPORT __MPESubsystemBreakHandler,CODE
+ 	.SPACE $PRIVATE$
+ 	.SUBSPA $DATA$
+ 
+ 	.align 4
+ L$C0001
+ 	.word P%__MPESubsystemBreakHandler
+ 	.SPACE $TEXT$
+ 	.SUBSPA $CODE$
+ 
+ 	.align 4
+ 	.EXPORT __MPEArmSubsystemBreak,ENTRY,PRIV_LEV=3
+ __MPEArmSubsystemBreak
+ 	.PROC
+ 	.CALLINFO FRAME=128,CALLS,SAVE_RP
+ 	.ENTRY
+ 	stw %r2,-20(0,%r30)
+ 	ldo 128(%r30),%r30
+ 	addil LR'L$C0001-$global$,%r27
+ 	ldw RR'L$C0001-$global$(%r1),%r26
+ 	.CALL ARGW0=GR,ARGW1=GR
+ 	bl XCONTRAP,%r2
+ 	ldo -120(%r30),%r25
+ 	ldw -148(0,%r30),%r2
+ 	bv 0(%r2)
+ 	ldo -128(%r30),%r30
+ 	.EXIT
+ 	.PROCEND
+ 	.IMPORT RESETCONTROL,CODE
+ 	.IMPORT kill,CODE
+ 	.align 4
+ 	.EXPORT __MPESubsystemBreakHandler,ENTRY,PRIV_LEV=3
+ __MPESubsystemBreakHandler
+ 	.PROC
+ 	.CALLINFO FRAME=128,CALLS,SAVE_RP
+ 	.ENTRY
+ 	stw %r2,-20(0,%r30)
+ 	.CALL 
+ 	bl RESETCONTROL,%r2
+ 	ldo 128(%r30),%r30
+ 	ldi 0,%r26
+ 	.CALL ARGW0=GR,ARGW1=GR
+ 	bl kill,%r2
+ 	ldi 2,%r25
+ 	ldw -148(0,%r30),%r2
+ 	bv 0(%r2)
+ 	ldo -128(%r30),%r30
+ 	.EXIT
+ 	.PROCEND

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Explanation:

Handle certain MPE nuances such as bcopy() not being able to do
overlapped moves. Invoke millicode instead of bcopy().

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * pa/xm-pampeix.h: New file for the MPE port.

*** egcs/gcc/config/pa/xm-pampeix.h	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/xm-pampeix.h	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,109 ----
+ /* Configuration for GNU C-compiler for PA-RISC.
+    Copyright (C) 1998 Free Software Foundation, Inc.
+    Contributed by Mark Klein (mklein@dis.com)           
+ 
+ This file is part of GNU CC.
+ 
+ GNU CC is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+ 
+ GNU CC is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with GNU CC; see the file COPYING.  If not, write to
+ the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+ 
+ 
+ #ifndef _POSIX_SOURCE
+ #define _POSIX_SOURCE
+ #endif
+ 
+ #define USG
+ 
+ /* Use System V memory functions.  */
+ #ifndef _BCMP_DEFINED
+ #define _BCMP_DEFINED
+ #ifndef BSTRING
+ #define BSTRING
+ #endif
+ #if !defined(bcopy) && !defined(HAS_BCOPY)
+ inline static void
+ bcopy(const void *src,void *dst,int len) {
+ 	asm volatile (
+ 			".import $$lr_unk_unk,MILLICODE;	
+ 			copy %0, %%r26;
+ 			copy %1, %%r25;
+ 			bl $$lr_unk_unk,%%r31;
+ 			copy %2, %%r24"
+ 					:
+ 					: "r" (src),
+ 					  "r" (dst),
+ 					  "r" (len)
+ 					: "%r24",
+ 					  "%r25",
+ 					  "%r26",
+ 					  "%r31");
+ }
+ #endif
+ #if !defined(bzero) && !defined(HAS_BZERO)
+ #define bzero(a,b) memset (a,0,b)
+ #endif
+ #if !defined(bcmp) && !defined(HAS_BCMP)
+ #define bcmp(a,b,c) memcmp (a,b,c)
+ #endif
+ #endif
+ 
+ #if !defined(rindex) && !defined(HAS_RINDEX)
+ #define rindex strrchr
+ #endif
+ #if !defined(index) && !defined(HAS_INDEX)
+ #define index strchr
+ #endif
+ 
+ /* #defines that need visibility everywhere.  */
+ #define FALSE 0
+ #define TRUE 1
+ 
+ /* This describes the machine the compiler is hosted on.  */
+ #define HOST_BITS_PER_CHAR 8
+ #define HOST_BITS_PER_SHORT 16
+ #define HOST_BITS_PER_INT 32
+ #define HOST_BITS_PER_LONG 32
+ #define HOST_BITS_PER_LONGLONG 64
+ 
+ /* Doubles are stored in memory with the high order word first.  This
+    matters when cross-compiling.  */
+ #define HOST_WORDS_BIG_ENDIAN 1
+ 
+ /* Place any machine-dependent include files here, in case we
+    are bootstrapping.  */
+ 
+ /* target machine dependencies.
+    tm.h is a symbolic link to the actual target specific file.   */
+ #include "tm.h"
+ 
+ /* Arguments to use with `exit'.  */
+ #define SUCCESS_EXIT_CODE 0
+ #define FATAL_EXIT_CODE 33
+ 
+ /* Don't try to use sys_siglist.  */
+ #define NO_SYS_SIGLIST
+ 
+ /* HP's compiler has problems with enum bitfields.  */
+ #define ONLY_INT_FIELDS
+ 
+ #ifndef _MPEIX_SOURCE
+ #define _MPEIX_SOURCE
+ #endif
+ 
+ /* If not compiled with GNU C, use C alloca.  */
+ #ifndef __GNUC__
+ #define USE_C_ALLOCA
+ #endif
+ 
+ #define STARTFILE_SPEC		""

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906102604.00c75df0@garfield.dis.com >you write:
  > Explanation:
  > 
  > Handle certain MPE nuances such as bcopy() not being able to do
  > overlapped moves. Invoke millicode instead of bcopy().
  > 
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * pa/xm-pampeix.h: New file for the MPE port.
  > 
  > *** egcs/gcc/config/pa/xm-pampeix.h	Wed Dec 31 16:00:00 1969
  > --- egcs-ss/gcc/config/pa/xm-pampeix.h	Mon Aug 30 21:52:06 1999
  > ***************
  > *** 0 ****
  > --- 1,109 ----
  > + /* Configuration for GNU C-compiler for PA-RISC.
  > +    Copyright (C) 1998 Free Software Foundation, Inc.
  > +    Contributed by Mark Klein (mklein@dis.com)           
Copyright date.

  > + You should have received a copy of the GNU General Public License
  > + along with GNU CC; see the file COPYING.  If not, write to
  > + the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
Address update.

  > + /* Use System V memory functions.  */
  > + #ifndef _BCMP_DEFINED
  > + #define _BCMP_DEFINED
  > + #ifndef BSTRING
  > + #define BSTRING
  > + #endif
  > + #if !defined(bcopy) && !defined(HAS_BCOPY)
  > + inline static void
  > + bcopy(const void *src,void *dst,int len) {
  > + 	asm volatile (
  > + 			".import $$lr_unk_unk,MILLICODE;	
  > + 			copy %0, %%r26;
  > + 			copy %1, %%r25;
  > + 			bl $$lr_unk_unk,%%r31;
  > + 			copy %2, %%r24"
  > + 					:
  > + 					: "r" (src),
  > + 					  "r" (dst),
  > + 					  "r" (len)
  > + 					: "%r24",
  > + 					  "%r25",
  > + 					  "%r26",
  > + 					  "%r31");
  > + }
  > + #endif
Ouch.  I presume you do not have a function memcpy, memmove or similar routine?

I'd like to hold off on that fragment for now -- we may be able to make the
entire point moot by having libiberty available for host and build machines.


  > + #define STARTFILE_SPEC		""
?!?  This does not belong in an xm.h file.


jeff

Re: MPE Port

[Mark Klein]

At 02:46 AM 9/8/99 -0600, Jeffrey A Law wrote:

>  > + inline static void
>  > + bcopy(const void *src,void *dst,int len) {
>  > +  asm volatile (
[snip]
>Ouch.  I presume you do not have a function memcpy, memmove or similar
routine?

Actually, bcopy, memcpy and memmove are all entry points into a small piece of
assembly code that assumes ripple moves are not supported.  This code in 
cp/class.c then fails:

                  /* We know the last slot in the vector is empty
                     because we know that at this point there's room
                     for a new function.  */
                  bcopy ((PTR) &TREE_VEC_ELT (method_vec, slot),
                         (PTR) &TREE_VEC_ELT (method_vec, slot + 1),
                         (len - slot - 1) * sizeof (tree));

Using the "move left to right unknown" millicode is not as efficient as that
in bcopy and friends, but it does support overlapped moves. While not
necessarily
pretty, it is efficient and serves the purpose.

>I'd like to hold off on that fragment for now -- we may be able to make the
>entire point moot by having libiberty available for host and build machines.

OK.

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 02:46 AM 9/8/99 -0600, Jeffrey A Law wrote:

>  > + inline static void
>  > + bcopy(const void *src,void *dst,int len) {
>  > +  asm volatile (
[snip]
>Ouch.  I presume you do not have a function memcpy, memmove or similar
routine?

Actually, bcopy, memcpy and memmove are all entry points into a small piece of
assembly code that assumes ripple moves are not supported.  This code in 
cp/class.c then fails:

                  /* We know the last slot in the vector is empty
                     because we know that at this point there's room
                     for a new function.  */
                  bcopy ((PTR) &TREE_VEC_ELT (method_vec, slot),
                         (PTR) &TREE_VEC_ELT (method_vec, slot + 1),
                         (len - slot - 1) * sizeof (tree));

Using the "move left to right unknown" millicode is not as efficient as that
in bcopy and friends, but it does support overlapped moves. While not
necessarily
pretty, it is efficient and serves the purpose.

>I'd like to hold off on that fragment for now -- we may be able to make the
>entire point moot by having libiberty available for host and build machines.

OK.

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906102604.00c75df0@garfield.dis.com >you write:
  > Explanation:
  > 
  > Handle certain MPE nuances such as bcopy() not being able to do
  > overlapped moves. Invoke millicode instead of bcopy().
  > 
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * pa/xm-pampeix.h: New file for the MPE port.
  > 
  > *** egcs/gcc/config/pa/xm-pampeix.h	Wed Dec 31 16:00:00 1969
  > --- egcs-ss/gcc/config/pa/xm-pampeix.h	Mon Aug 30 21:52:06 1999
  > ***************
  > *** 0 ****
  > --- 1,109 ----
  > + /* Configuration for GNU C-compiler for PA-RISC.
  > +    Copyright (C) 1998 Free Software Foundation, Inc.
  > +    Contributed by Mark Klein (mklein@dis.com)           
Copyright date.

  > + You should have received a copy of the GNU General Public License
  > + along with GNU CC; see the file COPYING.  If not, write to
  > + the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
Address update.

  > + /* Use System V memory functions.  */
  > + #ifndef _BCMP_DEFINED
  > + #define _BCMP_DEFINED
  > + #ifndef BSTRING
  > + #define BSTRING
  > + #endif
  > + #if !defined(bcopy) && !defined(HAS_BCOPY)
  > + inline static void
  > + bcopy(const void *src,void *dst,int len) {
  > + 	asm volatile (
  > + 			".import $$lr_unk_unk,MILLICODE;	
  > + 			copy %0, %%r26;
  > + 			copy %1, %%r25;
  > + 			bl $$lr_unk_unk,%%r31;
  > + 			copy %2, %%r24"
  > + 					:
  > + 					: "r" (src),
  > + 					  "r" (dst),
  > + 					  "r" (len)
  > + 					: "%r24",
  > + 					  "%r25",
  > + 					  "%r26",
  > + 					  "%r31");
  > + }
  > + #endif
Ouch.  I presume you do not have a function memcpy, memmove or similar routine?

I'd like to hold off on that fragment for now -- we may be able to make the
entire point moot by having libiberty available for host and build machines.


  > + #define STARTFILE_SPEC		""
?!?  This does not belong in an xm.h file.


jeff

Re: MPE Port

[Mark Klein]

Explanation:

Handle certain MPE nuances such as bcopy() not being able to do
overlapped moves. Invoke millicode instead of bcopy().

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * pa/xm-pampeix.h: New file for the MPE port.

*** egcs/gcc/config/pa/xm-pampeix.h	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/xm-pampeix.h	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,109 ----
+ /* Configuration for GNU C-compiler for PA-RISC.
+    Copyright (C) 1998 Free Software Foundation, Inc.
+    Contributed by Mark Klein (mklein@dis.com)           
+ 
+ This file is part of GNU CC.
+ 
+ GNU CC is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+ 
+ GNU CC is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with GNU CC; see the file COPYING.  If not, write to
+ the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+ 
+ 
+ #ifndef _POSIX_SOURCE
+ #define _POSIX_SOURCE
+ #endif
+ 
+ #define USG
+ 
+ /* Use System V memory functions.  */
+ #ifndef _BCMP_DEFINED
+ #define _BCMP_DEFINED
+ #ifndef BSTRING
+ #define BSTRING
+ #endif
+ #if !defined(bcopy) && !defined(HAS_BCOPY)
+ inline static void
+ bcopy(const void *src,void *dst,int len) {
+ 	asm volatile (
+ 			".import $$lr_unk_unk,MILLICODE;	
+ 			copy %0, %%r26;
+ 			copy %1, %%r25;
+ 			bl $$lr_unk_unk,%%r31;
+ 			copy %2, %%r24"
+ 					:
+ 					: "r" (src),
+ 					  "r" (dst),
+ 					  "r" (len)
+ 					: "%r24",
+ 					  "%r25",
+ 					  "%r26",
+ 					  "%r31");
+ }
+ #endif
+ #if !defined(bzero) && !defined(HAS_BZERO)
+ #define bzero(a,b) memset (a,0,b)
+ #endif
+ #if !defined(bcmp) && !defined(HAS_BCMP)
+ #define bcmp(a,b,c) memcmp (a,b,c)
+ #endif
+ #endif
+ 
+ #if !defined(rindex) && !defined(HAS_RINDEX)
+ #define rindex strrchr
+ #endif
+ #if !defined(index) && !defined(HAS_INDEX)
+ #define index strchr
+ #endif
+ 
+ /* #defines that need visibility everywhere.  */
+ #define FALSE 0
+ #define TRUE 1
+ 
+ /* This describes the machine the compiler is hosted on.  */
+ #define HOST_BITS_PER_CHAR 8
+ #define HOST_BITS_PER_SHORT 16
+ #define HOST_BITS_PER_INT 32
+ #define HOST_BITS_PER_LONG 32
+ #define HOST_BITS_PER_LONGLONG 64
+ 
+ /* Doubles are stored in memory with the high order word first.  This
+    matters when cross-compiling.  */
+ #define HOST_WORDS_BIG_ENDIAN 1
+ 
+ /* Place any machine-dependent include files here, in case we
+    are bootstrapping.  */
+ 
+ /* target machine dependencies.
+    tm.h is a symbolic link to the actual target specific file.   */
+ #include "tm.h"
+ 
+ /* Arguments to use with `exit'.  */
+ #define SUCCESS_EXIT_CODE 0
+ #define FATAL_EXIT_CODE 33
+ 
+ /* Don't try to use sys_siglist.  */
+ #define NO_SYS_SIGLIST
+ 
+ /* HP's compiler has problems with enum bitfields.  */
+ #define ONLY_INT_FIELDS
+ 
+ #ifndef _MPEIX_SOURCE
+ #define _MPEIX_SOURCE
+ #endif
+ 
+ /* If not compiled with GNU C, use C alloca.  */
+ #ifndef __GNUC__
+ #define USE_C_ALLOCA
+ #endif
+ 
+ #define STARTFILE_SPEC		""

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Explanation:

This is a punt per your recommendation. :-)


Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * libio/mpeix.mt: New file for MPE port.

*** egcs/libio/config/mpeix.mt	Wed Dec 31 16:00:00 1969
--- egcs-ss/libio/config/mpeix.mt	Wed Sep  1 20:57:00 1999
***************
*** 0 ****
--- 1,20 ----
+ # Flags to pass to gen-params when building _G_config.h.
+ # For example: G_CONFIG_ARGS = size_t="unsigned long"
+ G_CONFIG_ARGS = DOLLAR_IN_LABEL=1 
+ 
+ #
+ # gen-params tries to determine whether or not printf_fp exists by
+ # simply compiling a test program. Since MPE is by definition a
+ # shared runtime environment, this won't work unless the resulting
+ # program is run. Simply run _G_config.h through a sed script to
+ # update the values accordingly.
+ #
+ _G_CONFIG_H = stmp-Gconfig
+ 
+ stmp-Gconfig: $(_G_CONFIG_H) 
+ 	sed -e "s/_G_HAVE_PRINTF_FP 1/_G_HAVE_PRINTF_FP 0/" \
+ 	    -e "s/_G_HAVE_LONG_DOUBLE_IO 1/_G_HAVE_LONG_DOUBLE_IO 0/" \
+ 	    <_G_config.h > tmp-config.h
+ 	mv -f tmp-config.h _G_config.h
+ 	touch stmp-Gconfig
+ 	$(MAKE) $(FLAGS_TO_PASS) _G_CONFIG_H=_G_config.h all

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Explanation:

This is a punt per your recommendation. :-)


Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * libio/mpeix.mt: New file for MPE port.

*** egcs/libio/config/mpeix.mt	Wed Dec 31 16:00:00 1969
--- egcs-ss/libio/config/mpeix.mt	Wed Sep  1 20:57:00 1999
***************
*** 0 ****
--- 1,20 ----
+ # Flags to pass to gen-params when building _G_config.h.
+ # For example: G_CONFIG_ARGS = size_t="unsigned long"
+ G_CONFIG_ARGS = DOLLAR_IN_LABEL=1 
+ 
+ #
+ # gen-params tries to determine whether or not printf_fp exists by
+ # simply compiling a test program. Since MPE is by definition a
+ # shared runtime environment, this won't work unless the resulting
+ # program is run. Simply run _G_config.h through a sed script to
+ # update the values accordingly.
+ #
+ _G_CONFIG_H = stmp-Gconfig
+ 
+ stmp-Gconfig: $(_G_CONFIG_H) 
+ 	sed -e "s/_G_HAVE_PRINTF_FP 1/_G_HAVE_PRINTF_FP 0/" \
+ 	    -e "s/_G_HAVE_LONG_DOUBLE_IO 1/_G_HAVE_LONG_DOUBLE_IO 0/" \
+ 	    <_G_config.h > tmp-config.h
+ 	mv -f tmp-config.h _G_config.h
+ 	touch stmp-Gconfig
+ 	$(MAKE) $(FLAGS_TO_PASS) _G_CONFIG_H=_G_config.h all

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Explanation:

MPE/iX is a late binding OS, so simply compiling and linking a test
program to prove the existence of various routines won't work. I've
built a customized autoconf where the ac_link macro also attempts to
run what it links. It does so in a fashion such that if the final
bind is successful, then the program will not actually be run 
because in most cases, it will fail, which will still give a 
false negative. 

This script simply finds all cases of configure.in scripts that
are autoconf versions, not Cygnus versions.


Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * configure.mpe: New file for MPE port.

*** egcs/configure.mpe	Wed Dec 31 16:00:00 1969
--- egcs-ss/configure.mpe	Mon Aug 30 21:51:54 1999
***************
*** 0 ****
--- 1,31 ----
+ #
+ # MPE is by definition a "shared" environment and the configure scripts
+ # will fail to correctly determine whether or not something exists by
+ # simply doing a compile. Rerun autoconf to update the configure scripts.
+ # Use the autoconf from 
+ #   http://jazz.external.hp.com/src/gnu/gnu_tools/gnutools.html
+ #
+ # Find configure.in scripts containing AC_INIT and run autoconf in those
+ # directories.
+ for f in `find . -name configure.in` 
+ do
+ 	fgrep AC_INIT ${f} > /dev/null
+ 	if [ $? = 0 ] 
+ 	then
+ 		echo Processing ${f}
+ 		(cd `dirname ${f}`; autoconf)
+ 	fi
+ done
+ 
+ export CFLAGS="-I/usr/contrib/include -DSYSV -D_POSIX_SOURCE
-D_SOCKET_SOURCE \
+   -D_MPEIX_SOURCE -D_MPEXL_SOURCE"
+ export CXXFLAGS="$CFLAGS"
+ export CPPFLAGS="$CFLAGS"
+ export LDFLAGS="-lsocket -lcurses -lsvipc -ldce"
+ export CC=gcc
+ export CPP="gcc -E"
+ 
+ mkdir obj-MPE
+ cd obj-MPE
+ ../configure --with-gnu-as --disable-pic --disable-shared
--enable-threads=dce
+ # ../configure --with-gnu-as --disable-pic --disable-shared 

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Explanation:

MPE/iX is a late binding OS, so simply compiling and linking a test
program to prove the existence of various routines won't work. I've
built a customized autoconf where the ac_link macro also attempts to
run what it links. It does so in a fashion such that if the final
bind is successful, then the program will not actually be run 
because in most cases, it will fail, which will still give a 
false negative. 

This script simply finds all cases of configure.in scripts that
are autoconf versions, not Cygnus versions.


Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * configure.mpe: New file for MPE port.

*** egcs/configure.mpe	Wed Dec 31 16:00:00 1969
--- egcs-ss/configure.mpe	Mon Aug 30 21:51:54 1999
***************
*** 0 ****
--- 1,31 ----
+ #
+ # MPE is by definition a "shared" environment and the configure scripts
+ # will fail to correctly determine whether or not something exists by
+ # simply doing a compile. Rerun autoconf to update the configure scripts.
+ # Use the autoconf from 
+ #   http://jazz.external.hp.com/src/gnu/gnu_tools/gnutools.html
+ #
+ # Find configure.in scripts containing AC_INIT and run autoconf in those
+ # directories.
+ for f in `find . -name configure.in` 
+ do
+ 	fgrep AC_INIT ${f} > /dev/null
+ 	if [ $? = 0 ] 
+ 	then
+ 		echo Processing ${f}
+ 		(cd `dirname ${f}`; autoconf)
+ 	fi
+ done
+ 
+ export CFLAGS="-I/usr/contrib/include -DSYSV -D_POSIX_SOURCE
-D_SOCKET_SOURCE \
+   -D_MPEIX_SOURCE -D_MPEXL_SOURCE"
+ export CXXFLAGS="$CFLAGS"
+ export CPPFLAGS="$CFLAGS"
+ export LDFLAGS="-lsocket -lcurses -lsvipc -ldce"
+ export CC=gcc
+ export CPP="gcc -E"
+ 
+ mkdir obj-MPE
+ cd obj-MPE
+ ../configure --with-gnu-as --disable-pic --disable-shared
--enable-threads=dce
+ # ../configure --with-gnu-as --disable-pic --disable-shared 

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * pa/pa-mpeix.h: New file for MPE port.

*** egcs/gcc/config/pa/pa-mpeix.h	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/pa-mpeix.h	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,240 ----
+ /* Definitions of target machine for GNU compiler, for MPEiX.
+    Contributed by Mark Klein <mklein@dis.com>
+    Copyright (C) 1998 Free Software Foundation, Inc.
+ 
+ This file is part of GNU CC.
+ 
+ GNU CC is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+ 
+ GNU CC is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with GNU CC; see the file COPYING.  If not, write to
+ the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+ 
+ #undef TARGET_DEFAULT
+ #define TARGET_DEFAULT (MASK_GAS | MASK_JUMP_IN_DELAY | MASK_USE_MILLICODE)
+ 
+ /* MPE (as of MPE/iX 6.5) still uses older millicode than HP-UX. */
+ #undef  TARGET_NEW_MILLICODE
+ #define TARGET_NEW_MILLICODE 0
+
+ /* Make GCC agree with types.h.  */
+ #undef SIZE_TYPE
+ #undef PTRDIFF_TYPE
+ 
+ #define SIZE_TYPE "unsigned int"
+ #define PTRDIFF_TYPE "int"
+ 
+ #undef LINK_SPEC
+ #define LINK_SPEC ""
+ 
+ #undef LIB_SPEC
+ #define LIB_SPEC "%{!p:%{!pg:%{!threads:-lc}}}%{p:-lc_p}%{pg:-lc_p}
%{threads:/SYS/PUB/start.o -WL,xl=threadxl.pub.sys}"
+ 
+ #undef CPP_PREDEFINES
+ #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
-Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"
+   
+ #undef LDD_SUFFIX
+ 
+ /* Readonly data on MPE must be in $DATA$ to be available across
+    space boundaries for the intrinsic mechanism.
+  */
+ #undef SELECT_RTX_SECTION
+ #define SELECT_RTX_SECTION(MODE,RTX) data_section ();
+ 
+ #undef READONLY_DATA_ASM_OP
+ #define READONLY_DATA_ASM_OP "\t.SPACE $PRIVATE$\n\t.SUBSPA $DATA$\n"
+   
+ /* Ugly hack, but I don't see any other way.
+  * Gotta enable the <Control Y> traps, otherwise SIG_INT won't work.
+  */
+ #undef DO_GLOBAL_CTORS_BODY
+ #define DO_GLOBAL_CTORS_BODY						\
+ do {									\
+   extern __MPEArmSubsystemBreak();					\
+   unsigned long nptrs = (unsigned long) __CTOR_LIST__[0];		\
+   unsigned i;								\
+   if (nptrs == -1)							\
+     for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++);		\
+   for (i = nptrs; i >= 1; i--)						\
+     __CTOR_LIST__[i] ();						\
+   __MPEArmSubsystemBreak();   						\
+ } while (0) 
+ 
+ /* HPUX needs gcc_plt_call for gdb. Since gdb is not yet running on
+  * MPE and I think that gcc_plt_call will need an MPE variant, use
+  * the following in lieu of the DO_GLOBAL_DTORS_BODY declared in pa.h
+  */
+ #undef DO_GLOBAL_DTORS_BODY
+ #define DO_GLOBAL_DTORS_BODY			\
+ do {						\
+   func_ptr *p;					\
+   for (p = __DTOR_LIST__ + 1; *p; )		\
+     (*p++) ();					\
+ } while (0)
+ 
+ 
+ /* Gotta worry about priv_lev on MPE, so this is different from
+  * the HP-UX defn.
+  */
+ #undef  ASM_DECLARE_FUNCTION_NAME
+ #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
+     do { tree fntype = TREE_TYPE (TREE_TYPE (DECL));			\
+ 	 tree tree_type = TREE_TYPE (DECL);				\
+ 	 tree parm;							\
+ 	 int i;								\
+ 	 if (TREE_PUBLIC (DECL) || TARGET_GAS)				\
+ 	   { extern int current_function_varargs;			\
+ 	     if (TREE_PUBLIC (DECL))					\
+ 	       {							\
+ 		 fputs ("\t.EXPORT ", FILE);				\
+ 		 assemble_name (FILE, NAME);				\
+ 		 fputs (",ENTRY,PRIV_LEV=3", FILE);			\
+ 	       }							\
+ 	     else							\
+ 	       {							\
+ 		 fputs ("\t.PARAM ", FILE);				\
+ 		 assemble_name (FILE, NAME);				\
+ 		 fputs (",PRIV_LEV=3", FILE);				\
+ 	       }							\
+ 	     if (TARGET_PORTABLE_RUNTIME)				\
+ 	       {							\
+ 		 fputs (",ARGW0=NO,ARGW1=NO,ARGW2=NO,ARGW3=NO,", FILE);	\
+ 		 fputs ("RTNVAL=NO\n", FILE);				\
+ 		 break;							\
+ 	       }							\
+ 	     for (parm = DECL_ARGUMENTS (DECL), i = 0; parm && i < 4;	\
+ 		  parm = TREE_CHAIN (parm))				\
+ 	       {							\
+ 		 if (TYPE_MODE (DECL_ARG_TYPE (parm)) == SFmode		\
+ 		     && ! TARGET_SOFT_FLOAT)				\
+ 		   fprintf (FILE, ",ARGW%d=FR", i++);			\
+ 		 else if (TYPE_MODE (DECL_ARG_TYPE (parm)) == DFmode	\
+ 			  && ! TARGET_SOFT_FLOAT)			\
+ 		   {							\
+ 		     if (i <= 2)					\
+ 		       {						\
+ 			 if (i == 1) i++;				\
+ 			 ASM_DOUBLE_ARG_DESCRIPTORS (FILE, i++, i++);	\
+ 		       }						\
+ 		     else						\
+ 		       break;						\
+ 		   }							\
+ 		 else							\
+ 		   {							\
+ 		     int arg_size =					\
+ 		       FUNCTION_ARG_SIZE (TYPE_MODE (DECL_ARG_TYPE (parm)),\
+ 					  DECL_ARG_TYPE (parm));	\
+ 		     /* Passing structs by invisible reference uses	\
+ 			one general register.  */			\
+ 		     if (arg_size > 2					\
+ 			 || TREE_ADDRESSABLE (DECL_ARG_TYPE (parm)))	\
+ 		       arg_size = 1;					\
+ 		     if (arg_size == 2 && i <= 2)			\
+ 		       {						\
+ 			 if (i == 1) i++;				\
+ 			 fprintf (FILE, ",ARGW%d=GR", i++);		\
+ 			 fprintf (FILE, ",ARGW%d=GR", i++);		\
+ 		       }						\
+ 		     else if (arg_size == 1)				\
+ 		       fprintf (FILE, ",ARGW%d=GR", i++);		\
+ 		     else						\
+ 		       i += arg_size;					\
+ 		   }							\
+ 	       }							\
+ 	     /* anonymous args */					\
+ 	     if ((TYPE_ARG_TYPES (tree_type) != 0			\
+ 		  && (TREE_VALUE (tree_last (TYPE_ARG_TYPES (tree_type)))\
+ 		      != void_type_node))				\
+ 		 || current_function_varargs)				\
+ 	       {							\
+ 		 for (; i < 4; i++)					\
+ 		   fprintf (FILE, ",ARGW%d=GR", i);			\
+ 	       }							\
+ 	     if (TYPE_MODE (fntype) == DFmode && ! TARGET_SOFT_FLOAT)	\
+ 	       fputs (DFMODE_RETURN_STRING, FILE);			\
+ 	     else if (TYPE_MODE (fntype) == SFmode && ! TARGET_SOFT_FLOAT) \
+ 	       fputs (SFMODE_RETURN_STRING, FILE);			\
+ 	     else if (fntype != void_type_node)				\
+ 	       fputs (",RTNVAL=GR", FILE);				\
+ 	     fputs ("\n", FILE);					\
+ 	   }} while (0)
+ 
+ /* This is another ugly hack. Compilation units must be named
+  * if we ever want to extract them by name. Since making libgcc
+  * does this, I added a new pseudo command .compiler that is used
+  * to communicate the names to gas.
+  */
+ #undef ASM_IDENTIFY_GCC
+ #define ASM_IDENTIFY_GCC(FILE) 						\
+ 	do {								\
+ 		fputs ("; gcc_compiled.:\n", FILE);			\
+ 		fprintf (FILE, "\t.compiler \"%s %s %s\"\n",		\
+ 			 main_input_filename,				\
+ 			 "GNU_C_Compiler",				\
+ 			 version_string);				\
+ 	} while (0)
+ 
+ 
+ /*
+  * Long double support for MPE. The Quad functions are part of the PRO
+  * ABI, but it appears that I'm the only one interested in Quad support
+  * on PA, so I'll declare and support it only for MPE.
+  */
+ #undef LONG_DOUBLE_TYPE_SIZE
+ #define LONG_DOUBLE_TYPE_SIZE 128
+ 
+ /* This is how to output an assembler line defining a `long double'
constant. */
+ 
+ #undef ASM_OUTPUT_LONG_DOUBLE
+ #define ASM_OUTPUT_LONG_DOUBLE(FILE,VALUE)  \
+   do { long l[4];							\
+        REAL_VALUE_TO_TARGET_LONG_DOUBLE (VALUE, l);			\
+        fprintf (FILE, "\t.word 0x%lx\n\t.word 0x%lx\n", l[0], l[1]);	\
+        fprintf (FILE, "\t.word 0x%lx\n\t.word 0x%lx\n", l[2], l[3]);	\
+      } while (0)
+ 
+ #undef INIT_TARGET_OPTABS
+ #define INIT_TARGET_OPTABS						\
+   do {									\
+     add_optab->handlers[(int) TFmode].libfunc				\
+       = gen_rtx_SYMBOL_REF (Pmode, ADDTF3_LIBCALL);			\
+     sub_optab->handlers[(int) TFmode].libfunc				\
+       = gen_rtx_SYMBOL_REF (Pmode, SUBTF3_LIBCALL);			\
+     smul_optab->handlers[(int) TFmode].libfunc				\
+       = gen_rtx_SYMBOL_REF (Pmode, MULTF3_LIBCALL);			\
+     flodiv_optab->handlers[(int) TFmode].libfunc			\
+       = gen_rtx_SYMBOL_REF (Pmode, DIVTF3_LIBCALL);			\
+     neg_optab->handlers[(int) TFmode].libfunc				\
+       = gen_rtx_SYMBOL_REF (Pmode, NEGTF2_LIBCALL);			\
+     eqtf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, EQTF2_LIBCALL);          \
+     netf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, NETF2_LIBCALL);          \
+     gttf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, GTTF2_LIBCALL);          \
+     getf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, GETF2_LIBCALL);          \
+     lttf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, LTTF2_LIBCALL);          \
+     letf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, LETF2_LIBCALL);          \
+     trunctfsf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, TRUNCTFSF2_LIBCALL);   \
+     trunctfdf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, TRUNCTFDF2_LIBCALL);   \
+     extendsftf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, EXTENDSFTF2_LIBCALL); \
+     extenddftf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, EXTENDDFTF2_LIBCALL); \
+     floatsitf_libfunc = gen_rtx_SYMBOL_REF (Pmode, FLOATSITF2_LIBCALL);    \
+     floatditf_libfunc = gen_rtx_SYMBOL_REF (Pmode, FLOATDITF2_LIBCALL);    \
+     fixtfsi_libfunc = gen_rtx_SYMBOL_REF (Pmode, FIX_TRUNCTFSI2_LIBCALL);  \
+     fixtfdi_libfunc = gen_rtx_SYMBOL_REF (Pmode, FIX_TRUNCTFDI2_LIBCALL);  \
+     fixunstfsi_libfunc							\
+       = gen_rtx_SYMBOL_REF (Pmode, FIXUNS_TRUNCTFSI2_LIBCALL);		\
+     fixunstfdi_libfunc							\
+       = gen_rtx_SYMBOL_REF (Pmode, FIXUNS_TRUNCTFDI2_LIBCALL);		\
+     sqrt_optab->handlers[(int) TFmode].libfunc			\
+ 	= gen_rtx_SYMBOL_REF (Pmode, "_U_Qfsqrt");			\
+   } while (0)
+ 
+ #undef TARGET_VERSION
+ #define TARGET_VERSION fputs (" (hppa - MPE Threaded)", stderr);

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906102304.00c72c80@garfield.dis.com >you write:
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * pa/pa-mpeix.h: New file for MPE port.
Several comments :-)


  > *** egcs/gcc/config/pa/pa-mpeix.h	Wed Dec 31 16:00:00 1969
  > --- egcs-ss/gcc/config/pa/pa-mpeix.h	Mon Aug 30 21:52:06 1999
  > ***************
  > *** 0 ****
  > --- 1,240 ----
  > + /* Definitions of target machine for GNU compiler, for MPEiX.
  > +    Contributed by Mark Klein <mklein@dis.com>
  > +    Copyright (C) 1998 Free Software Foundation, Inc.
Make sure to add 1999 to the copyright header.


  > + You should have received a copy of the GNU General Public License
  > + along with GNU CC; see the file COPYING.  If not, write to
  > + the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
  > + 
This appears to be the old FSF address.  You need to update the files to have
the new FSF address:

You should have received a copy of the GNU General Public License
along with GNU CC; see the file COPYING.  If not, write to
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.  */


  > + #undef TARGET_DEFAULT
  > + #define TARGET_DEFAULT (MASK_GAS | MASK_JUMP_IN_DELAY | MASK_USE_MILLICOD
  > E)
  > + 
  > + /* MPE (as of MPE/iX 6.5) still uses older millicode than HP-UX. */
  > + #undef  TARGET_NEW_MILLICODE
  > + #define TARGET_NEW_MILLICODE 0
In general try to avoid names like NEW/OLD, since there will always be
something newer.  For example, PA64 has a yet newer millicode scheme.  Do we
call it NEW_NEW_MILLICODE :-)? 

Is there some better way to describe it?  ie, what are the characteristics of
this scheme that make it different from the scheme found with PA32 SOM HPUX
conventions?

Or better yet, is there a name for it?

  > + #undef CPP_PREDEFINES
  > + #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
  > -Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"
You should move the -D definitions into a CPP_SPEC string to avoid ANSI
namespace pollution.


  > + /* Ugly hack, but I don't see any other way.
  > +  * Gotta enable the <Control Y> traps, otherwise SIG_INT won't work.
  > +  */
:-)   As I mentioned before, I do not think this belongs in gcc.  A cleaner
way to do this is to provide this functionality in a library routine that
users can link with.  To ensure it runs before main you can declare the
magic function as a constructor (using the constructor attribute).

On a style note we write multi-line comments like:

  /* blah blah blah
     boo hoo
     This is a sentence.  */

Nearly every one of your comments used the wrong style.

  > + 
  > + /* HPUX needs gcc_plt_call for gdb. Since gdb is not yet running on
  > +  * MPE and I think that gcc_plt_call will need an MPE variant, use
  > +  * the following in lieu of the DO_GLOBAL_DTORS_BODY declared in pa.h
  > +  */
What you'll need to do to find out is determine whether or not your runtime
linker allows a return location from a call to be a stack address.

If it does, then you will not need a stub.  If it does not, then you will need
a stub.  The stub is most likely going to be identical to __gcc_plt_call since
it's only purpose is to sit in the text segment to shut up the overly pedantic
runtime linker.


  > + #undef  ASM_DECLARE_FUNCTION_NAME
  > + #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
  > +     do { tree fntype = TREE_TYPE (TREE_TYPE (DECL));		
  > 	\
  > + 	 tree tree_type = TREE_TYPE (DECL);				\
  > + 	 tree parm;							\
  > + 	 int i;								\
  > + 	 if (TREE_PUBLIC (DECL) || TARGET_GAS)				\
  > + 	   { extern int current_function_varargs;			\
  > + 	     if (TREE_PUBLIC (DECL))					\
  > + 	       {							\
  > + 		 fputs ("\t.EXPORT ", FILE);				\
  > + 		 assemble_name (FILE, NAME);				\
  > + 		 fputs (",ENTRY,PRIV_LEV=3", FILE);			\
  > + 	       }							\
  > + 	     else							\
  > + 	       {							\
  > + 		 fputs ("\t.PARAM ", FILE);				\
  > + 		 assemble_name (FILE, NAME);				\
  > + 		 fputs (",PRIV_LEV=3", FILE);				\
If the only difference is that you need a PRIV_LEV=3 on a static function, I
see no reason we can't promote that into som.h.  I believe that would
eliminate the need for a separate ASM_DECLARE_FUNCTION_NAME, right?

Even if you need to be different we can easily conditionalize the code in
som.h a little, which would avoid a lot of code duplication.

  > + 	       }							\
  > + 	     if (TARGET_PORTABLE_RUNTIME)				\
  > + 	       {							\
  > + 		 fputs (",ARGW0=NO,ARGW1=NO,ARGW2=NO,ARGW3=NO,", FILE);	\
  > + 		 fputs ("RTNVAL=NO\n", FILE);				\
  > + 		 break;							\
  > + 	       }							\
If you end up with a separate ASM_DECLARE_FUNCTION_NAME you certainly do
not need TARGET_PORTABLE_RUNTIME support ;-)


  > + /* This is another ugly hack. Compilation units must be named
  > +  * if we ever want to extract them by name. Since making libgcc
  > +  * does this, I added a new pseudo command .compiler that is used
  > +  * to communicate the names to gas.
  > +  */
  > + #undef ASM_IDENTIFY_GCC
  > + #define ASM_IDENTIFY_GCC(FILE) 					
  > 	\
  > + 	do {								\
  > + 		fputs ("; gcc_compiled.:\n", FILE);			\
  > + 		fprintf (FILE, "\t.compiler \"%s %s %s\"\n",		\
  > + 			 main_input_filename,				\
  > + 			 "GNU_C_Compiler",				\
  > + 			 version_string);				\
  > + 	} while (0)
Only problem with this is formatting.  I strongly recommend you read the GNU
coding standards.

  do {
    fputs ("...");
    fprintf (...");
  } while (0)

Two space indention for nesting levels please, not tabs, not four spaces, but
two.  


  > + /*
  > +  * Long double support for MPE. The Quad functions are part of the PRO
  > +  * ABI, but it appears that I'm the only one interested in Quad support
  > +  * on PA, so I'll declare and support it only for MPE.
  > +  */
  > + #undef LONG_DOUBLE_TYPE_SIZE
  > + #define LONG_DOUBLE_TYPE_SIZE 128
Presumably you had to fix up other code to handle this :-)  I know it doesn't
"just work" :-)  I started down the 128bit long double road with the PA64
port and realized that it wasn't all that simple ;-)

  > + /* This is how to output an assembler line defining a `long double'
  > constant. */
/* This is how to output an assembler line defining a `long double'
   constant.  */

Note the indention.  Also two spaces after a period ending a sentence.

Basically it was OK -- most of the issues are style nits that you should be
able to clean up quickly and resubmit.

Thanks,
jeff

Re: MPE Port

[Mark Klein]

At 04:04 AM 9/7/99 -0600, Jeffrey A Law wrote:

>  In message < 4.1.19990906102304.00c72c80@garfield.dis.com >you write:
>  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
>  > 
>  >         * pa/pa-mpeix.h: New file for MPE port.
>Several comments :-)

Got it. This was a file I forgot to fix for style when I did the others.
I'll do it and resubmit.

Re: the comment about long double ... yes, it did take more things
elsewhere in the code. Why? Did you want me to submit the long double
as a separate patch?
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990907064456.00c2ddf0@garfield.dis.com >you write:
  > Re: the comment about long double ... yes, it did take more things
  > elsewhere in the code. Why? Did you want me to submit the long double
  > as a separate patch?
No, let's continue how we're doing things now.

It was mostly a comment that I'm expecting changes elsewhere later to make
that actually work ;-)


jeff

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990907064456.00c2ddf0@garfield.dis.com >you write:
  > Re: the comment about long double ... yes, it did take more things
  > elsewhere in the code. Why? Did you want me to submit the long double
  > as a separate patch?
No, let's continue how we're doing things now.

It was mostly a comment that I'm expecting changes elsewhere later to make
that actually work ;-)


jeff

Re: MPE Port

[Mark Klein]

At 04:04 AM 9/7/99 -0600, Jeffrey A Law wrote:

>  In message < 4.1.19990906102304.00c72c80@garfield.dis.com >you write:
>  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
>  > 
>  >         * pa/pa-mpeix.h: New file for MPE port.
>Several comments :-)

Got it. This was a file I forgot to fix for style when I did the others.
I'll do it and resubmit.

Re: the comment about long double ... yes, it did take more things
elsewhere in the code. Why? Did you want me to submit the long double
as a separate patch?
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Jeffrey A Law]

  In message < 4.1.19990906102304.00c72c80@garfield.dis.com >you write:
  > Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)
  > 
  >         * pa/pa-mpeix.h: New file for MPE port.
Several comments :-)


  > *** egcs/gcc/config/pa/pa-mpeix.h	Wed Dec 31 16:00:00 1969
  > --- egcs-ss/gcc/config/pa/pa-mpeix.h	Mon Aug 30 21:52:06 1999
  > ***************
  > *** 0 ****
  > --- 1,240 ----
  > + /* Definitions of target machine for GNU compiler, for MPEiX.
  > +    Contributed by Mark Klein <mklein@dis.com>
  > +    Copyright (C) 1998 Free Software Foundation, Inc.
Make sure to add 1999 to the copyright header.


  > + You should have received a copy of the GNU General Public License
  > + along with GNU CC; see the file COPYING.  If not, write to
  > + the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
  > + 
This appears to be the old FSF address.  You need to update the files to have
the new FSF address:

You should have received a copy of the GNU General Public License
along with GNU CC; see the file COPYING.  If not, write to
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.  */


  > + #undef TARGET_DEFAULT
  > + #define TARGET_DEFAULT (MASK_GAS | MASK_JUMP_IN_DELAY | MASK_USE_MILLICOD
  > E)
  > + 
  > + /* MPE (as of MPE/iX 6.5) still uses older millicode than HP-UX. */
  > + #undef  TARGET_NEW_MILLICODE
  > + #define TARGET_NEW_MILLICODE 0
In general try to avoid names like NEW/OLD, since there will always be
something newer.  For example, PA64 has a yet newer millicode scheme.  Do we
call it NEW_NEW_MILLICODE :-)? 

Is there some better way to describe it?  ie, what are the characteristics of
this scheme that make it different from the scheme found with PA32 SOM HPUX
conventions?

Or better yet, is there a name for it?

  > + #undef CPP_PREDEFINES
  > + #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
  > -Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"
You should move the -D definitions into a CPP_SPEC string to avoid ANSI
namespace pollution.


  > + /* Ugly hack, but I don't see any other way.
  > +  * Gotta enable the <Control Y> traps, otherwise SIG_INT won't work.
  > +  */
:-)   As I mentioned before, I do not think this belongs in gcc.  A cleaner
way to do this is to provide this functionality in a library routine that
users can link with.  To ensure it runs before main you can declare the
magic function as a constructor (using the constructor attribute).

On a style note we write multi-line comments like:

  /* blah blah blah
     boo hoo
     This is a sentence.  */

Nearly every one of your comments used the wrong style.

  > + 
  > + /* HPUX needs gcc_plt_call for gdb. Since gdb is not yet running on
  > +  * MPE and I think that gcc_plt_call will need an MPE variant, use
  > +  * the following in lieu of the DO_GLOBAL_DTORS_BODY declared in pa.h
  > +  */
What you'll need to do to find out is determine whether or not your runtime
linker allows a return location from a call to be a stack address.

If it does, then you will not need a stub.  If it does not, then you will need
a stub.  The stub is most likely going to be identical to __gcc_plt_call since
it's only purpose is to sit in the text segment to shut up the overly pedantic
runtime linker.


  > + #undef  ASM_DECLARE_FUNCTION_NAME
  > + #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
  > +     do { tree fntype = TREE_TYPE (TREE_TYPE (DECL));		
  > 	\
  > + 	 tree tree_type = TREE_TYPE (DECL);				\
  > + 	 tree parm;							\
  > + 	 int i;								\
  > + 	 if (TREE_PUBLIC (DECL) || TARGET_GAS)				\
  > + 	   { extern int current_function_varargs;			\
  > + 	     if (TREE_PUBLIC (DECL))					\
  > + 	       {							\
  > + 		 fputs ("\t.EXPORT ", FILE);				\
  > + 		 assemble_name (FILE, NAME);				\
  > + 		 fputs (",ENTRY,PRIV_LEV=3", FILE);			\
  > + 	       }							\
  > + 	     else							\
  > + 	       {							\
  > + 		 fputs ("\t.PARAM ", FILE);				\
  > + 		 assemble_name (FILE, NAME);				\
  > + 		 fputs (",PRIV_LEV=3", FILE);				\
If the only difference is that you need a PRIV_LEV=3 on a static function, I
see no reason we can't promote that into som.h.  I believe that would
eliminate the need for a separate ASM_DECLARE_FUNCTION_NAME, right?

Even if you need to be different we can easily conditionalize the code in
som.h a little, which would avoid a lot of code duplication.

  > + 	       }							\
  > + 	     if (TARGET_PORTABLE_RUNTIME)				\
  > + 	       {							\
  > + 		 fputs (",ARGW0=NO,ARGW1=NO,ARGW2=NO,ARGW3=NO,", FILE);	\
  > + 		 fputs ("RTNVAL=NO\n", FILE);				\
  > + 		 break;							\
  > + 	       }							\
If you end up with a separate ASM_DECLARE_FUNCTION_NAME you certainly do
not need TARGET_PORTABLE_RUNTIME support ;-)


  > + /* This is another ugly hack. Compilation units must be named
  > +  * if we ever want to extract them by name. Since making libgcc
  > +  * does this, I added a new pseudo command .compiler that is used
  > +  * to communicate the names to gas.
  > +  */
  > + #undef ASM_IDENTIFY_GCC
  > + #define ASM_IDENTIFY_GCC(FILE) 					
  > 	\
  > + 	do {								\
  > + 		fputs ("; gcc_compiled.:\n", FILE);			\
  > + 		fprintf (FILE, "\t.compiler \"%s %s %s\"\n",		\
  > + 			 main_input_filename,				\
  > + 			 "GNU_C_Compiler",				\
  > + 			 version_string);				\
  > + 	} while (0)
Only problem with this is formatting.  I strongly recommend you read the GNU
coding standards.

  do {
    fputs ("...");
    fprintf (...");
  } while (0)

Two space indention for nesting levels please, not tabs, not four spaces, but
two.  


  > + /*
  > +  * Long double support for MPE. The Quad functions are part of the PRO
  > +  * ABI, but it appears that I'm the only one interested in Quad support
  > +  * on PA, so I'll declare and support it only for MPE.
  > +  */
  > + #undef LONG_DOUBLE_TYPE_SIZE
  > + #define LONG_DOUBLE_TYPE_SIZE 128
Presumably you had to fix up other code to handle this :-)  I know it doesn't
"just work" :-)  I started down the 128bit long double road with the PA64
port and realized that it wasn't all that simple ;-)

  > + /* This is how to output an assembler line defining a `long double'
  > constant. */
/* This is how to output an assembler line defining a `long double'
   constant.  */

Note the indention.  Also two spaces after a period ending a sentence.

Basically it was OK -- most of the issues are style nits that you should be
able to clean up quickly and resubmit.

Thanks,
jeff

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * pa/pa-mpeix.h: New file for MPE port.

*** egcs/gcc/config/pa/pa-mpeix.h	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/pa-mpeix.h	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,240 ----
+ /* Definitions of target machine for GNU compiler, for MPEiX.
+    Contributed by Mark Klein <mklein@dis.com>
+    Copyright (C) 1998 Free Software Foundation, Inc.
+ 
+ This file is part of GNU CC.
+ 
+ GNU CC is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+ 
+ GNU CC is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with GNU CC; see the file COPYING.  If not, write to
+ the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+ 
+ #undef TARGET_DEFAULT
+ #define TARGET_DEFAULT (MASK_GAS | MASK_JUMP_IN_DELAY | MASK_USE_MILLICODE)
+ 
+ /* MPE (as of MPE/iX 6.5) still uses older millicode than HP-UX. */
+ #undef  TARGET_NEW_MILLICODE
+ #define TARGET_NEW_MILLICODE 0
+
+ /* Make GCC agree with types.h.  */
+ #undef SIZE_TYPE
+ #undef PTRDIFF_TYPE
+ 
+ #define SIZE_TYPE "unsigned int"
+ #define PTRDIFF_TYPE "int"
+ 
+ #undef LINK_SPEC
+ #define LINK_SPEC ""
+ 
+ #undef LIB_SPEC
+ #define LIB_SPEC "%{!p:%{!pg:%{!threads:-lc}}}%{p:-lc_p}%{pg:-lc_p}
%{threads:/SYS/PUB/start.o -WL,xl=threadxl.pub.sys}"
+ 
+ #undef CPP_PREDEFINES
+ #define CPP_PREDEFINES "-Dhppa -Dhp3000s900 -D__hp3000s900 -Dhp3k9
-Dmpeix -Dhp3000 -DREVARGV -Asystem(mpeix) -Acpu(hppa) -Amachine(hppa)"
+   
+ #undef LDD_SUFFIX
+ 
+ /* Readonly data on MPE must be in $DATA$ to be available across
+    space boundaries for the intrinsic mechanism.
+  */
+ #undef SELECT_RTX_SECTION
+ #define SELECT_RTX_SECTION(MODE,RTX) data_section ();
+ 
+ #undef READONLY_DATA_ASM_OP
+ #define READONLY_DATA_ASM_OP "\t.SPACE $PRIVATE$\n\t.SUBSPA $DATA$\n"
+   
+ /* Ugly hack, but I don't see any other way.
+  * Gotta enable the <Control Y> traps, otherwise SIG_INT won't work.
+  */
+ #undef DO_GLOBAL_CTORS_BODY
+ #define DO_GLOBAL_CTORS_BODY						\
+ do {									\
+   extern __MPEArmSubsystemBreak();					\
+   unsigned long nptrs = (unsigned long) __CTOR_LIST__[0];		\
+   unsigned i;								\
+   if (nptrs == -1)							\
+     for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++);		\
+   for (i = nptrs; i >= 1; i--)						\
+     __CTOR_LIST__[i] ();						\
+   __MPEArmSubsystemBreak();   						\
+ } while (0) 
+ 
+ /* HPUX needs gcc_plt_call for gdb. Since gdb is not yet running on
+  * MPE and I think that gcc_plt_call will need an MPE variant, use
+  * the following in lieu of the DO_GLOBAL_DTORS_BODY declared in pa.h
+  */
+ #undef DO_GLOBAL_DTORS_BODY
+ #define DO_GLOBAL_DTORS_BODY			\
+ do {						\
+   func_ptr *p;					\
+   for (p = __DTOR_LIST__ + 1; *p; )		\
+     (*p++) ();					\
+ } while (0)
+ 
+ 
+ /* Gotta worry about priv_lev on MPE, so this is different from
+  * the HP-UX defn.
+  */
+ #undef  ASM_DECLARE_FUNCTION_NAME
+ #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
+     do { tree fntype = TREE_TYPE (TREE_TYPE (DECL));			\
+ 	 tree tree_type = TREE_TYPE (DECL);				\
+ 	 tree parm;							\
+ 	 int i;								\
+ 	 if (TREE_PUBLIC (DECL) || TARGET_GAS)				\
+ 	   { extern int current_function_varargs;			\
+ 	     if (TREE_PUBLIC (DECL))					\
+ 	       {							\
+ 		 fputs ("\t.EXPORT ", FILE);				\
+ 		 assemble_name (FILE, NAME);				\
+ 		 fputs (",ENTRY,PRIV_LEV=3", FILE);			\
+ 	       }							\
+ 	     else							\
+ 	       {							\
+ 		 fputs ("\t.PARAM ", FILE);				\
+ 		 assemble_name (FILE, NAME);				\
+ 		 fputs (",PRIV_LEV=3", FILE);				\
+ 	       }							\
+ 	     if (TARGET_PORTABLE_RUNTIME)				\
+ 	       {							\
+ 		 fputs (",ARGW0=NO,ARGW1=NO,ARGW2=NO,ARGW3=NO,", FILE);	\
+ 		 fputs ("RTNVAL=NO\n", FILE);				\
+ 		 break;							\
+ 	       }							\
+ 	     for (parm = DECL_ARGUMENTS (DECL), i = 0; parm && i < 4;	\
+ 		  parm = TREE_CHAIN (parm))				\
+ 	       {							\
+ 		 if (TYPE_MODE (DECL_ARG_TYPE (parm)) == SFmode		\
+ 		     && ! TARGET_SOFT_FLOAT)				\
+ 		   fprintf (FILE, ",ARGW%d=FR", i++);			\
+ 		 else if (TYPE_MODE (DECL_ARG_TYPE (parm)) == DFmode	\
+ 			  && ! TARGET_SOFT_FLOAT)			\
+ 		   {							\
+ 		     if (i <= 2)					\
+ 		       {						\
+ 			 if (i == 1) i++;				\
+ 			 ASM_DOUBLE_ARG_DESCRIPTORS (FILE, i++, i++);	\
+ 		       }						\
+ 		     else						\
+ 		       break;						\
+ 		   }							\
+ 		 else							\
+ 		   {							\
+ 		     int arg_size =					\
+ 		       FUNCTION_ARG_SIZE (TYPE_MODE (DECL_ARG_TYPE (parm)),\
+ 					  DECL_ARG_TYPE (parm));	\
+ 		     /* Passing structs by invisible reference uses	\
+ 			one general register.  */			\
+ 		     if (arg_size > 2					\
+ 			 || TREE_ADDRESSABLE (DECL_ARG_TYPE (parm)))	\
+ 		       arg_size = 1;					\
+ 		     if (arg_size == 2 && i <= 2)			\
+ 		       {						\
+ 			 if (i == 1) i++;				\
+ 			 fprintf (FILE, ",ARGW%d=GR", i++);		\
+ 			 fprintf (FILE, ",ARGW%d=GR", i++);		\
+ 		       }						\
+ 		     else if (arg_size == 1)				\
+ 		       fprintf (FILE, ",ARGW%d=GR", i++);		\
+ 		     else						\
+ 		       i += arg_size;					\
+ 		   }							\
+ 	       }							\
+ 	     /* anonymous args */					\
+ 	     if ((TYPE_ARG_TYPES (tree_type) != 0			\
+ 		  && (TREE_VALUE (tree_last (TYPE_ARG_TYPES (tree_type)))\
+ 		      != void_type_node))				\
+ 		 || current_function_varargs)				\
+ 	       {							\
+ 		 for (; i < 4; i++)					\
+ 		   fprintf (FILE, ",ARGW%d=GR", i);			\
+ 	       }							\
+ 	     if (TYPE_MODE (fntype) == DFmode && ! TARGET_SOFT_FLOAT)	\
+ 	       fputs (DFMODE_RETURN_STRING, FILE);			\
+ 	     else if (TYPE_MODE (fntype) == SFmode && ! TARGET_SOFT_FLOAT) \
+ 	       fputs (SFMODE_RETURN_STRING, FILE);			\
+ 	     else if (fntype != void_type_node)				\
+ 	       fputs (",RTNVAL=GR", FILE);				\
+ 	     fputs ("\n", FILE);					\
+ 	   }} while (0)
+ 
+ /* This is another ugly hack. Compilation units must be named
+  * if we ever want to extract them by name. Since making libgcc
+  * does this, I added a new pseudo command .compiler that is used
+  * to communicate the names to gas.
+  */
+ #undef ASM_IDENTIFY_GCC
+ #define ASM_IDENTIFY_GCC(FILE) 						\
+ 	do {								\
+ 		fputs ("; gcc_compiled.:\n", FILE);			\
+ 		fprintf (FILE, "\t.compiler \"%s %s %s\"\n",		\
+ 			 main_input_filename,				\
+ 			 "GNU_C_Compiler",				\
+ 			 version_string);				\
+ 	} while (0)
+ 
+ 
+ /*
+  * Long double support for MPE. The Quad functions are part of the PRO
+  * ABI, but it appears that I'm the only one interested in Quad support
+  * on PA, so I'll declare and support it only for MPE.
+  */
+ #undef LONG_DOUBLE_TYPE_SIZE
+ #define LONG_DOUBLE_TYPE_SIZE 128
+ 
+ /* This is how to output an assembler line defining a `long double'
constant. */
+ 
+ #undef ASM_OUTPUT_LONG_DOUBLE
+ #define ASM_OUTPUT_LONG_DOUBLE(FILE,VALUE)  \
+   do { long l[4];							\
+        REAL_VALUE_TO_TARGET_LONG_DOUBLE (VALUE, l);			\
+        fprintf (FILE, "\t.word 0x%lx\n\t.word 0x%lx\n", l[0], l[1]);	\
+        fprintf (FILE, "\t.word 0x%lx\n\t.word 0x%lx\n", l[2], l[3]);	\
+      } while (0)
+ 
+ #undef INIT_TARGET_OPTABS
+ #define INIT_TARGET_OPTABS						\
+   do {									\
+     add_optab->handlers[(int) TFmode].libfunc				\
+       = gen_rtx_SYMBOL_REF (Pmode, ADDTF3_LIBCALL);			\
+     sub_optab->handlers[(int) TFmode].libfunc				\
+       = gen_rtx_SYMBOL_REF (Pmode, SUBTF3_LIBCALL);			\
+     smul_optab->handlers[(int) TFmode].libfunc				\
+       = gen_rtx_SYMBOL_REF (Pmode, MULTF3_LIBCALL);			\
+     flodiv_optab->handlers[(int) TFmode].libfunc			\
+       = gen_rtx_SYMBOL_REF (Pmode, DIVTF3_LIBCALL);			\
+     neg_optab->handlers[(int) TFmode].libfunc				\
+       = gen_rtx_SYMBOL_REF (Pmode, NEGTF2_LIBCALL);			\
+     eqtf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, EQTF2_LIBCALL);          \
+     netf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, NETF2_LIBCALL);          \
+     gttf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, GTTF2_LIBCALL);          \
+     getf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, GETF2_LIBCALL);          \
+     lttf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, LTTF2_LIBCALL);          \
+     letf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, LETF2_LIBCALL);          \
+     trunctfsf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, TRUNCTFSF2_LIBCALL);   \
+     trunctfdf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, TRUNCTFDF2_LIBCALL);   \
+     extendsftf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, EXTENDSFTF2_LIBCALL); \
+     extenddftf2_libfunc = gen_rtx_SYMBOL_REF (Pmode, EXTENDDFTF2_LIBCALL); \
+     floatsitf_libfunc = gen_rtx_SYMBOL_REF (Pmode, FLOATSITF2_LIBCALL);    \
+     floatditf_libfunc = gen_rtx_SYMBOL_REF (Pmode, FLOATDITF2_LIBCALL);    \
+     fixtfsi_libfunc = gen_rtx_SYMBOL_REF (Pmode, FIX_TRUNCTFSI2_LIBCALL);  \
+     fixtfdi_libfunc = gen_rtx_SYMBOL_REF (Pmode, FIX_TRUNCTFDI2_LIBCALL);  \
+     fixunstfsi_libfunc							\
+       = gen_rtx_SYMBOL_REF (Pmode, FIXUNS_TRUNCTFSI2_LIBCALL);		\
+     fixunstfdi_libfunc							\
+       = gen_rtx_SYMBOL_REF (Pmode, FIXUNS_TRUNCTFDI2_LIBCALL);		\
+     sqrt_optab->handlers[(int) TFmode].libfunc			\
+ 	= gen_rtx_SYMBOL_REF (Pmode, "_U_Qfsqrt");			\
+   } while (0)
+ 
+ #undef TARGET_VERSION
+ #define TARGET_VERSION fputs (" (hppa - MPE Threaded)", stderr);

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Explanation:

This provides the interface to the quad library as specified in the
PRO spec. This is implemented on MPE and HP-UX, but I don't know
about the other PA platforms. Long Double support is enabled by
default for MPE only.

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * pa/quadlib.asm: New file for long double support for the MPE port.

*** egcs/gcc/config/pa/quadlib.asm	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/quadlib.asm	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,359 ----
+ ;  Subroutines for long double support on the HPPA
+ ;  Copyright (C) 1999 Free Software Foundation, Inc.
+ 
+ ;  This file is part of GNU CC.
+ 
+ ;  GNU CC is free software; you can redistribute it and/or modify
+ ;  it under the terms of the GNU General Public License as published by
+ ;  the Free Software Foundation; either version 2, or (at your option)
+ ;  any later version.
+ 
+ ;  GNU CC is distributed in the hope that it will be useful,
+ ;  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ ;  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ ;  GNU General Public License for more details.
+ 
+ ; In addition to the permissions in the GNU General Public License, the
+ ; Free Software Foundation gives you unlimited permission to link the
+ ; compiled version of this file with other programs, and to distribute
+ ; those programs without any restriction coming from the use of this
+ ; file.  (The General Public License restrictions do apply in other
+ ; respects; for example, they cover modification of the file, and
+ ; distribution when not linked into another program.)
+ 
+ ;  You should have received a copy of the GNU General Public License
+ ;  along with GNU CC; see the file COPYING.  If not, write to
+ ;  the Free Software Foundation, 59 Temple Place - Suite 330,
+ ;  Boston, MA 02111-1307, USA.
+ 
+ 	.SPACE $TEXT$
+ 	.SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
+ 	.compiler "quadlib.asm GNU_PA-RISC_Assembler 2.9.4"
+ 	.IMPORT _U_Qfcmp,CODE
+ 	.IMPORT _U_Qfsub,CODE
+ 
+ 	.align 4
+ 	.NSUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
+ 	;
+ 	; Check two long doubles for equality
+ 	;
+ 	.EXPORT _U_Qfeq,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfeq
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	  ldi 4,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check two long doubles for inequality
+ 	;
+ 	.EXPORT _U_Qfne,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfne
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 4,%r24
+ 	
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,<> 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30),%r30
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check if opnd1 > opnd0                
+ 	;
+ 	.EXPORT _U_Qfgt,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfgt
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 23,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check if opnd1 >= opnd0                
+ 	;
+ 	.EXPORT _U_Qfge,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfge
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 23,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check if opnd1 < opnd0                
+ 	;
+ 	.EXPORT _U_Qflt,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qflt
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 9,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check if opnd1 <= opnd0                
+ 	;
+ 	.EXPORT _U_Qfle,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfle
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 13,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Negate opnd0 and store in ret0                 
+ 	;
+ 	.EXPORT _U_Qfneg,ENTRY,PRIV_LEV=3,ARGW0=GR,RTNVAL=GR
+ _U_Qfneg
+ 	.PROC
+ 	.CALLINFO FRAME=128,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 128(%r30),%r30
+ 
+ 	;
+ 	; copy the value to be negated to the frame.
+ 	;
+ 	ldw 0(0,%r26), %r25
+ 	ldw 4(0,%r26), %r24
+ 	ldw 8(0,%r26), %r23
+ 	ldw 12(0,%r26),%r1
+ 	stw %r25, -100(0,%r30)
+ 	stw %r24,  -96(0,%r30)
+ 	stw %r23,  -92(0,%r30)
+ 	stw %r1,   -88(0,%r30)
+ 	ldo -100(%r30), %r25
+ 
+ 	;
+ 	; ret0 contains a pointer to the location for the return
+ 	; value. Initialize it to zero and pass it as arg0 to
+ 	; _U_Qfsub.
+ 	;
+ 	copy %r28,%r26
+ 	stw %r0,0(0,%r26)
+ 	stw %r0,4(0,%r26)
+ 	stw %r0,8(0,%r26)
+ 	bl _U_Qfsub,%r2
+ 	  stw %r0,12(0,%r26)
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -148(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -128(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Compare opnd0 and opnd1. If opnd0 == opnd1, return 0.
+ 	; If opnd0 is greater than opnd1, return 1.
+ 	; Otherwise, return -1.
+ 	;
+ 	.EXPORT _U_Qfcomp,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfcomp
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Save arg0 and arg1.
+ 	;
+ 	stw %r26, -60(0,%r30)
+ 	stw %r25, -56(0,%r30)
+ 	;
+ 	; Check for equality
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	  ldi 4, %r24
+ 
+ 	comib,<> 0,%r28,done
+ 	  copy %r0, %r1
+ 
+ 	;
+ 	; Reset the parms and test for opnd0 > opnd1.
+ 	;
+ 	ldw -60(0,%r30),%r26
+ 	ldw -56(0,%r30),%r25
+ 	bl _U_Qfcmp,%r2
+ 	  ldi 22,%r24
+ 
+ 	ldi 1,%r1
+ 	comiclr,<> 0,%r28,0
+ 	  ldi -1,%r1
+ 
+ done
+ 	copy %r1,%r28
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Explanation:

This provides the interface to the quad library as specified in the
PRO spec. This is implemented on MPE and HP-UX, but I don't know
about the other PA platforms. Long Double support is enabled by
default for MPE only.

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * pa/quadlib.asm: New file for long double support for the MPE port.

*** egcs/gcc/config/pa/quadlib.asm	Wed Dec 31 16:00:00 1969
--- egcs-ss/gcc/config/pa/quadlib.asm	Mon Aug 30 21:52:06 1999
***************
*** 0 ****
--- 1,359 ----
+ ;  Subroutines for long double support on the HPPA
+ ;  Copyright (C) 1999 Free Software Foundation, Inc.
+ 
+ ;  This file is part of GNU CC.
+ 
+ ;  GNU CC is free software; you can redistribute it and/or modify
+ ;  it under the terms of the GNU General Public License as published by
+ ;  the Free Software Foundation; either version 2, or (at your option)
+ ;  any later version.
+ 
+ ;  GNU CC is distributed in the hope that it will be useful,
+ ;  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ ;  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ ;  GNU General Public License for more details.
+ 
+ ; In addition to the permissions in the GNU General Public License, the
+ ; Free Software Foundation gives you unlimited permission to link the
+ ; compiled version of this file with other programs, and to distribute
+ ; those programs without any restriction coming from the use of this
+ ; file.  (The General Public License restrictions do apply in other
+ ; respects; for example, they cover modification of the file, and
+ ; distribution when not linked into another program.)
+ 
+ ;  You should have received a copy of the GNU General Public License
+ ;  along with GNU CC; see the file COPYING.  If not, write to
+ ;  the Free Software Foundation, 59 Temple Place - Suite 330,
+ ;  Boston, MA 02111-1307, USA.
+ 
+ 	.SPACE $TEXT$
+ 	.SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
+ 	.compiler "quadlib.asm GNU_PA-RISC_Assembler 2.9.4"
+ 	.IMPORT _U_Qfcmp,CODE
+ 	.IMPORT _U_Qfsub,CODE
+ 
+ 	.align 4
+ 	.NSUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
+ 	;
+ 	; Check two long doubles for equality
+ 	;
+ 	.EXPORT _U_Qfeq,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfeq
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	  ldi 4,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check two long doubles for inequality
+ 	;
+ 	.EXPORT _U_Qfne,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfne
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 4,%r24
+ 	
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,<> 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30),%r30
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check if opnd1 > opnd0                
+ 	;
+ 	.EXPORT _U_Qfgt,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfgt
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 23,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check if opnd1 >= opnd0                
+ 	;
+ 	.EXPORT _U_Qfge,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfge
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 23,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check if opnd1 < opnd0                
+ 	;
+ 	.EXPORT _U_Qflt,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qflt
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 9,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Check if opnd1 <= opnd0                
+ 	;
+ 	.EXPORT _U_Qfle,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfle
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Load the additional argument and call the comparison routine.
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	ldi 13,%r24
+ 
+ 	;
+ 	; The return from _U_Qfcmp is the masked C bit from the FP
+ 	; status register. Convert that to a 0 or 1.
+ 	;
+ 	comiclr,= 0,%r28,%r28
+ 	  ldi 1,%r28
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Negate opnd0 and store in ret0                 
+ 	;
+ 	.EXPORT _U_Qfneg,ENTRY,PRIV_LEV=3,ARGW0=GR,RTNVAL=GR
+ _U_Qfneg
+ 	.PROC
+ 	.CALLINFO FRAME=128,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 128(%r30),%r30
+ 
+ 	;
+ 	; copy the value to be negated to the frame.
+ 	;
+ 	ldw 0(0,%r26), %r25
+ 	ldw 4(0,%r26), %r24
+ 	ldw 8(0,%r26), %r23
+ 	ldw 12(0,%r26),%r1
+ 	stw %r25, -100(0,%r30)
+ 	stw %r24,  -96(0,%r30)
+ 	stw %r23,  -92(0,%r30)
+ 	stw %r1,   -88(0,%r30)
+ 	ldo -100(%r30), %r25
+ 
+ 	;
+ 	; ret0 contains a pointer to the location for the return
+ 	; value. Initialize it to zero and pass it as arg0 to
+ 	; _U_Qfsub.
+ 	;
+ 	copy %r28,%r26
+ 	stw %r0,0(0,%r26)
+ 	stw %r0,4(0,%r26)
+ 	stw %r0,8(0,%r26)
+ 	bl _U_Qfsub,%r2
+ 	  stw %r0,12(0,%r26)
+ 
+ 	;
+ 	; Return
+ 	;
+ 	ldw -148(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -128(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND
+ 
+ 	;
+ 	; Compare opnd0 and opnd1. If opnd0 == opnd1, return 0.
+ 	; If opnd0 is greater than opnd1, return 1.
+ 	; Otherwise, return -1.
+ 	;
+ 	.EXPORT _U_Qfcomp,ENTRY,PRIV_LEV=3,ARGW0=GR,ARGW1=GR,RTNVAL=GR
+ _U_Qfcomp
+ 	.PROC
+ 	.CALLINFO FRAME=64,CALLS,SAVE_RP
+ 	.ENTRY
+ 	;
+ 	; Build the frame
+ 	;
+ 	stw %r2,-20(0,%r30)
+ 	ldo 64(%r30),%r30
+ 
+ 	;
+ 	; Save arg0 and arg1.
+ 	;
+ 	stw %r26, -60(0,%r30)
+ 	stw %r25, -56(0,%r30)
+ 	;
+ 	; Check for equality
+ 	;
+ 	bl _U_Qfcmp,%r2
+ 	  ldi 4, %r24
+ 
+ 	comib,<> 0,%r28,done
+ 	  copy %r0, %r1
+ 
+ 	;
+ 	; Reset the parms and test for opnd0 > opnd1.
+ 	;
+ 	ldw -60(0,%r30),%r26
+ 	ldw -56(0,%r30),%r25
+ 	bl _U_Qfcmp,%r2
+ 	  ldi 22,%r24
+ 
+ 	ldi 1,%r1
+ 	comiclr,<> 0,%r28,0
+ 	  ldi -1,%r1
+ 
+ done
+ 	copy %r1,%r28
+ 	;
+ 	; Return
+ 	;
+ 	ldw -84(0,%r30),%r2
+ 	bv 0(%r2)
+ 	  ldo -64(%r30), %r30
+ 
+ 	.EXIT
+ 	.PROCEND

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * configure.in: Add hppa1.0-*-mpeix for MPE port.


*** egcs/gcc/configure.in	Mon Aug 30 21:50:10 1999
--- egcs-ss/gcc/configure.in	Mon Aug 30 21:52:09 1999
***************
*** 1019,1024 ****
--- 1019,1033 ----
  		target_cpu_default="MASK_PA_11"
  		use_collect2=yes
  		;;
+ 	hppa1.0-*-mpeix*)
+ 		tm_file="${tm_file} pa/pa-mpeix.h"
+ 		xm_file=pa/xm-pampeix.h 
+ 		xmake_file=pa/x-pa-mpeix 
+ 		echo "You must use gas. Assuming it is already installed." 
+ 		install_headers_dir=install-headers-tar
+ 		fixincludes=Makefile.in
+ 		use_collect2=yes 
+ 		;; 
  	i370-*-mvs*)
  		;;
  changequote(,)dnl
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

Sat Sep  4 18:00:00 PDT 1999 Mark Klein (mklein@dis.com)

        * configure.in: Add hppa1.0-*-mpeix for MPE port.


*** egcs/gcc/configure.in	Mon Aug 30 21:50:10 1999
--- egcs-ss/gcc/configure.in	Mon Aug 30 21:52:09 1999
***************
*** 1019,1024 ****
--- 1019,1033 ----
  		target_cpu_default="MASK_PA_11"
  		use_collect2=yes
  		;;
+ 	hppa1.0-*-mpeix*)
+ 		tm_file="${tm_file} pa/pa-mpeix.h"
+ 		xm_file=pa/xm-pampeix.h 
+ 		xmake_file=pa/x-pa-mpeix 
+ 		echo "You must use gas. Assuming it is already installed." 
+ 		install_headers_dir=install-headers-tar
+ 		fixincludes=Makefile.in
+ 		use_collect2=yes 
+ 		;; 
  	i370-*-mvs*)
  		;;
  changequote(,)dnl
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

At 03:59 PM 8/27/99 -0600, Jeffrey A Law wrote:

>My queue is over 200 patches deep.  And unfortunately MPE isn't anywhere near
>the top of the list.  Simply a matter of priorities.

OK. I'll keep tracking what you've got (thank heaven I ported CVS to MPE).
Let me know when you want me to repost them and I'll do so.

>:-)  I did something similar already.  We're still beating on it internally
>before we contribute it.

For sake of argument, here's mine. I reformatted it a bit to understand it
better. The only real changes are to handle the long double:

struct rtx_def *
function_arg(cum, mode, type, named)
  const CUMULATIVE_ARGS *cum;
  enum machine_mode mode;
  tree type;
  int named;
{
  rtx reg = 0;
  int basereg1 = 0;
  int basereg2 = 0;

  /*
   * See if there is at least one argument register still available.
   */
  if (4 >= cum->words + FUNCTION_ARG_SIZE (mode, type)) 
    {

    if (!TARGET_PORTABLE_RUNTIME        || 
        type == 0                       ||
        !FLOAT_MODE_P (mode)            ||
        TARGET_SOFT_FLOAT               ||
        cum->nargs_prototype > 0) 
      {
      if (FUNCTION_ARG_SIZE (mode, type) > 2)
        {
          /*
           * We're dealing with an argument greater than 2 words.
           * It must be passed in the frame by reference.
           */
          return 0;
        }

      if (FUNCTION_ARG_SIZE (mode, type) > 1)
        {
          /*
           * This is a multi-word parameter. If this is either a direct
           * call or the portable runtime and we're dealing with the
           * hardware FPU, place the argument in the argument into the
           * correct FARG, otherwise put it in a general register.
           */
          if ((!cum->indirect           || 
               TARGET_PORTABLE_RUNTIME) &&
               (mode) == DFmode         &&
               !TARGET_SOFT_FLOAT)
              basereg1 = (cum->words ? 38 : 34);
          else 
              basereg1 = (cum->words ? 23 : 25);
        }
      else 
        {
        /*
         * This is a single-word parameter. If this is either a direct
         * call or the portable runtime and we're dealing with the
         * hardware FPU, place the argument into the correct FARG,
         * otherwise put it into a general register.
         */
        if ((!cum->indirect             ||
             TARGET_PORTABLE_RUNTIME)   &&
             (mode) == SFmode           &&
             !TARGET_SOFT_FLOAT)
            basereg1 = (32 + 2 * cum->words);
        else 
            basereg1 = (27 - cum->words - FUNCTION_ARG_SIZE(mode, type));

        }
      /*
       * Generate the REG rtx for the current parameter.
       */
      reg = gen_rtx_REG (mode, basereg1);
      }
    else
      {
      /*
       * We need to place the argument in both floating args as well
       * as the general args.
       */
      if (FUNCTION_ARG_SIZE (mode, type) > 2)
        {
          /*
           * We're dealing with an argument greater than 2 words.
           * It must be passed in the frame by reference.
           */
          return 0;
        }

      if (FUNCTION_ARG_SIZE (mode, type) > 1)
        {
        basereg1 = (cum->words ? 38 : 34);
        basereg2 = (cum->words ? 23 : 25);
        }
      else
        {
        basereg1 = (32 + 2 * cum->words);
        basereg2 = (27 - cum->words - FUNCTION_ARG_SIZE (mode, type));
        }

      reg = gen_rtx_PARALLEL (mode, 
                gen_rtvec(2, 
                    gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_REG (mode, basereg1),
                                       const0_rtx),
                    gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_REG (mode, basereg2),
                                       const0_rtx)));
      }
    }
    return reg;
}
/DIS/GNU/src/egcs-ss/gcc/config/pa(134): 

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Jeffrey A Law]

  In message < 4.1.19990827171727.00c5a960@garfield.dis.com >you write:
  > OK. I'll keep tracking what you've got (thank heaven I ported CVS to MPE).
  > Let me know when you want me to repost them and I'll do so.
One possibility would be to try to deal with it in smaller hunks rather than
all at once.  We can start with stuff that is non-controversial then deal
with progressively more issues.

That way we can work to reduce the amount of patches you have to carry around
and we don't have to do a "mega patch" (which have the tendency to break
things).

So let's start with just your new config files and configure.in fragment
first.  Can you send just those pieces?


  > For sake of argument, here's mine. I reformatted it a bit to understand it
  > better. The only real changes are to handle the long double:
A few notes....

  > 
  > struct rtx_def *
  > function_arg(cum, mode, type, named)
  >   const CUMULATIVE_ARGS *cum;
  >   enum machine_mode mode;
  >   tree type;
  >   int named;
We always indent function arguments 5 spaces.  Not 2, not 4, not a tab, but
5 spaces (hell if I know why the GNU standards mandate 5 spaces).

  >   /*
  >    * See if there is at least one argument register still available.
  >    */
We write comments like

/* blah blah
   foo bar com.  */

  >   if (4 >= cum->words + FUNCTION_ARG_SIZE (mode, type)) 
  >     {
  > 
  >     if (!TARGET_PORTABLE_RUNTIME        || 
  >         type == 0                       ||
  >         !FLOAT_MODE_P (mode)            ||
  >         TARGET_SOFT_FLOAT               ||
  >         cum->nargs_prototype > 0) 
We write conditionals like
   if (cond1
       || cond2
       || cond3)



  >       {
  >       if (FUNCTION_ARG_SIZE (mode, type) > 2)
We always indent two spaces after an open-curley.

As for the actual code, I suspect it's similar to the stuff we're playing with
internally, but simpler :-)  The PA64 calling conventions are similar, but
not quite the same as the portable runtime.  Ugh.

It certainly is a hell of a lot easier to follow the code once it's broken out
into a function :-)  Probably the next one to break into a function on the PA
will be GO_IF_LEGITIMATE_ADDRESS.  The whole idea that we have macros that
take up a page is absurd.  Nobody should write code like that :-)

jeff

Re: MPE Port

[Mark Klein]

At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote:

>So let's start with just your new config files and configure.in fragment
>first.  Can you send just those pieces?

OK - I've reformatted and will repost momentarily. These are either the
new config files or changes to configure.in. There are also some MPE
specific README/scripts that I'm not sure how best to deal with. These
address the fact that some of the tools need customization for MPE before
they'll work. I'll post them as I have them at this moment and will change 
them as you see fit.

libobjc/thr-dce.c needs a small change and I've sent that along with
this as it could affect other DCE ports as well.

I'll sit on pa.c, pa.h and pa.md until I hear otherwise from you.

Thanks!

Regards,


M.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote:

>So let's start with just your new config files and configure.in fragment
>first.  Can you send just those pieces?

OK - I've reformatted and will repost momentarily. These are either the
new config files or changes to configure.in. There are also some MPE
specific README/scripts that I'm not sure how best to deal with. These
address the fact that some of the tools need customization for MPE before
they'll work. I'll post them as I have them at this moment and will change 
them as you see fit.

libobjc/thr-dce.c needs a small change and I've sent that along with
this as it could affect other DCE ports as well.

I'll sit on pa.c, pa.h and pa.md until I hear otherwise from you.

Thanks!

Regards,


M.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available