Re: MPE Port

[Mark Klein <mklein at dis dot com>]

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