Re: i370 port

["Paul Edwards" <mutazilah at gmail dot com>]

> This probably is not gimp (the graphics editor) but gmp (the
> multi-precision integer operation library) and mpfr (same for
> floating-point).  To build any recent GCC you'll indeed need
> these two libraries.  Fortunately, they're already available
> on s390(x) on Linux, and shouldn't really contain anything
> that is OS-specific, so porting those to MVS should hopefully
> be straightforward ...

Ok, thanks Ulrich.

> > 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:
> [snip]
> > 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.
>
> I don't think there is a reliable way to change the sequence of
> functions / objects in the output file.

Sorry, my question may not have been clear.

When I see main(), I generate the normal MAIN code, and I don't
care where this goes.

However, given that I now know that a main() exists somewhere
in this source file, I need to change the ASM_FILE_START
output.

I expected that the assembler generation wouldn't happen until
after the optimization was completed, and thus, by then, I
would know whether this was a main.

> However, it seems to me it shouldn't really be necessary to treat "main"
> special.  Usually, the "entry point" isn't really "main", but rather some
> function in crt0.o, which then in turn *calls* main after all startup
> processing has been done.

That is roughly the case, yes.

> As crt0.o can be (and usually is) completely
> written in assembler, you can arrange for everything to be in the sequence
> that is required.  (On the linker command line, crt0.o would be placed
> first, so if the entry point is the first thing in crt0.o it will then
> also be the first thing in the executable.)

Yes, I can do that, but that means I need to have a linker command
line!  The way the MVS linker works, I can link my main program,
(which obviously doesn't have crt0 in it), and, thanks to the "END"
statement, I can specify an entry point.  This means no complaint
from the linker about a default (and wrong) entry point, and no
need for any linker statements.  It all automatically resolves.

It all works really great!

Except - I would ideally like to have an entry point of 0, instead
of the typical "58" or whatever my static variables happen to be.
(my main is normally at the top).

> > 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?
>
> Hmm, this seems to be the bug fixed by Eric Christopher in 2004:
> http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg01425.html

Thanks again!  That didn't seem to make it into 3.4.6.  I was able
to apply most of his stuff to 3.4.6, and I will see how far that gets
me, before trying to find it in 3.2.3.

Or maybe I'll skip it, since the problem doesn't occur on a pure
EBCDIC system.  :-)

> > 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)");
>
> As you note, this doesn't seem workable as the result wouldn't
> be syntactically valid ...
>
> > 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?
>
> There doesn't seem to be an easy way to do this from the
> compiler.  At the time compiler output is generated, the
> original source code text isn't even kept any more; you'd
> have to go back and re-read the original source files using
> the line-number debug data, just as the assembler would ...

Ok, well - I would be content with just the source line number
appearing in the output assembler.  Is this information
available as each assembler line is output?

Thanks.  Paul.