This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i370 port


I then found out that even with old versions of the machine definition,
I can have the warning removed by simply not defining CONST_INT
in the PREDICATE_CODES, even though it is allowed when the
function is called.  ie it seems to have no effect on the code
generation, but succeeds in eliminating the warning, and without
needing to define an extra constraint for non-constant situations.

Actually PREDICATE_CODES does have to match the predicate definitions. If it does not, you can run into subtle bugs, as the code in genrecog.c that generates the finite state automaton matching an RTX pattern against the .md insn definitions *does* make use of PREDICATE_CODES; for example, it will assume that two predicates with disjoint sets of PREDICATE_CODES can never both match the same RTX.

This may or may not lead to visible differences when compiling simple
test cases, but I'd expect effects to be visible in more complex
scenarios.

Thanks Ulrich. When I went back to this I found that I had misdiagnosed - actually the r_or_s didn't allow constants after all. It was only const_rtx that it allowed. So the machine definition no longer has any warnings and all looks good.

That's with 3.2.3.

With 3.4.6 I have now managed to get an MVS load module,
unoptimized (I already know that optimized doesn't work), to
compile a hello world program successfully, although it abends
at the end of that and I haven't investigated that yet.

So the theoretical EBCDIC support is less theoretical now.
I "needed" to change the parameter search algorithm to stop
being binary search though.

GCC 4 complained (on my Linux system) that I didn't have
various things (gimp etc) installed, which means I would need
that other software to be ported too, which is not a project
I want to work on at the moment.  However, at least it means
that i have successfully merged all the GCCMVS changes
to 3.2.3 in with the (last available) 3.4.6 development, which
was a precursor to any GCC 4 port anyway.  I'll see over time
how GCC 3.4.6 pans out.

Until then, back at GCC 3.2.3, I have a "need" to make the entry
point 0 in my MVS modules.

Currently I generate this:

        COPY  PDPTOP
        CSECT
* X-var bytes
        ENTRY BYTES
* Program data area
        DS    0F
BYTES    EQU   *
        DC    F'258'
* Program text area
LC0      EQU   *
        DC    C'bytes is %d'
        DC    X'15'
        DC    X'0'
        DS    0F
        DC    C'GCCMVS!!'
        EXTRN @@CRT0
        ENTRY @@MAIN
@@MAIN   DS    0H
        USING *,15
        L     15,=V(@@CRT0)
        BR    15
        DROP  15
        LTORG
* X-func main prologue
MAIN     PDPPRLG CINDEX=0,FRAME=96,BASER=12,ENTRY=YES
...
* Function main page table
        DS    0F
PGT0     EQU   *
        DC    A(PG0)
        END   @@MAIN

for a main program. In order to get the entry point to 0, I need to move that
@@MAIN function to the top of the file.


But I only really want that function if this is a main program. I have found
somewhere where I can add some code to see if the function "main" is
being compiled, and set a global variable.


Unfortunately, the place that happens (c-decl) isn't called until after all
the data has been written out!

I looked at the documentation:

http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gccint/Assembler-Format.html#Assembler%20Format

but maybe I'm looking in the wrong place. Any ideas?

And I have another question - where is the code for __asm__?

Currently that is generating garbage for me:

unsigned int bytes = 258;

__asm__("? :");

int main(void)

BYTES    EQU   *
        DC    F'258'
        o@z
* Program text area

when done in cross-compiler mode, and need to find out where
the literal is being translated (or more likely - failing to be
translated in the first instance).  Any idea where that is?

And final thing - the interest in the __asm__ comes from the hope
that in the generated 370 assembler, it would be possible to have
the C code interspersed to whatever extent possible.  The plan was
to basically somehow get every line of C code, e.g. "int main(void)"
above, and automatically generate an:
__asm__("int main void)");

although I'm not sure what to do about this:

int main(void)
__asm__("? :");
{

which gives a syntax error.  Any idea how to get the mixed
C/assembler when I'm running with the "-S" option and don't
have the luxury of calling the normal "as" which would
normally handle that?

Thanks. Paul.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]