Re: tlug: 1run C++,Fortran,Ratfor makes

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Sean" == Sean Bennett <sean@example.com> writes:

    Sean> "Stephen J. Turnbull" wrote:

    >> Um, could you be more specific?

    Sean> (...details, details... always my undoing...)  ah, sorry but
    Sean> actually I can't be more specific right now :-(

Actually, this helps a lot.

    Sean> We have a client currently using SunOS systems, interested
    Sean> in moving to PC's running TL3.0.  As described to me after
    Sean> the fact, besides his hesitation regarding using gcc, he was
    Sean> looking for something that could handle multiple source
    Sean> files at the same time with a single 'make' command.

The quality of GCC code is high, as high as that of most commercial
compilers in most applications.  If your client has very special
requirements which involve intimate linkages to the operating system,
Linux may not be for them.  (The problem here would not be with GCC
per se, however, but with the linker.  Many people who want to use GCC
for some reason on various systems do so, but then let the system's ld
program link the output of the various compilers into a single
executable object.  Obviously, such a linker would not be available on
Linux.)

`make' is not a problem.  It is a standard component of all
development environments and has been for years.  I have never heard
of something that a proprietary make could do that GNU make cannot
(doesn't mean there aren't such), but the reverse is not true---GNU
make has several features that some proprietary makes do not, and
(last I heard) a very few features that are unique to GNU make.  As
Manu said, it is almost certain that your client can continue to use
his current Makefiles, perhaps with a few small tweaks.

I think you can confidently tell your client not to worry about those
issues in a narrow sense.  If they're worried about GCC enough that
they're willing to pay for Sun's compiler, there are plenty of high
quality proprietary 3rd party solutions _for Linux_ out there.

I don't think TL will have all this in a pretty package tied up with
a red ribbon; somebody's going to have to spend some time (and
probably money) putting the peices together---but it shouldn't be
difficult.

    >> I don't think this is a "make" issue at all, but a problem of
    >> linking the different calling conventions of the different
    >> languages.
    >> 
    >> Cf. the `extern "LANGUAGE" { ... }' construct of C++.

    Sean> ...? <gulp>...  'spose it wouldn't fly if I said I was
    Sean> thinking just the same thing :-)

<chortle>

The simplest example is that when a function is called, you pass it
arguments, eg

		   printf("My number is %d.", 10);

has two arguments, the string "My number is %d." and the integer 10.
These arguments are recognized by positions on a stack of values.

Now, when you enter the code that actually does the "printf"
operation, printf's arguments should be on top, so it will know where
to find them.  However, there are two natural orders.

The first is the lexical order, so that the string is on top and the
integer is second.  The other order is the reverse, and that happens
because first you put the string on top of the stack, and then you put
the integer on top of the string on top of the stack. OK?

The reverse order is easier to generate by compiler.  So why not do it
that way?  Because printf can have any number of arguments, and it
figures out how many by counting the number of `%'s in the string.  So
if the lexically first argument is always on top of the stack, it's
easy to find out how many arguments there are from _inside_ the printf
implementation (which doesn't get to see the source code).  Still OK?

Now suppose a compiler using lexical order tries to call a printf
compiled using reverse order (and some other way of finding the first
argument).  That would be like writing

		   printf(10, "My number is %d.");

except that the linkage error is not caught by the compiler or the
linker (at least not for most current linkers, it could be done in
theory), it happens at runtime (this one should give you the famous
`SIGSEGV' fatal error as `printf' tries to access a string somewhere
inside a "No Trespassing" zone).

So if you want to call a function in C++ that was compiled with a
different compiler or language, you can do something like

extern "reverse-arguments" {
    int printf (char *format, ...);
}

in the declarations.  In practice, instead of saying something
specific like "reverse-arguments", a whole set of conventions is
denoted by the language that uses them.  What declarations are
supported is implementation-dependent; all C++ compilers support
`extern "C"'; some also support `extern "Pascal"' and `extern
"FORTRAN"'.  It will also be vendor specific; few languages specify
the calling conventions, so two different vendors' FORTRANs may use
different implementations.  I don't know what GCC supports.

All of these things can be faked by use of preprocessor macros or very
tiny assembly language "wrapper functions".

As for availability of good FORTRAN and RATFOR, I think you needn't
worry.  Check Linux Journal (eg Jan 1999 fer shure) for the Microway
(don't be fooled by the hardware picture, read the ad) and Portland
Group ads.

As Manu says, FORTRAN libraries are critical.  But with Beowulf
looking to dominate the supercomputer market by number of
installations, I would suspect vendors are breaking their necks to
make sure they have Linux versions available yesterday.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
-------------------------------------------------------------------
Next Nomikai: 14 January 1999, 19:30 Tengu TokyoEkiMae 03-3275-3691
*** it will will be Jan 14 (Thu), as Jan 15 (Fri) is a natl holiday
Next Technical Meeting: Feb 13 (Sat), 12:30    ace: Temple Univ.
-------------------------------------------------------------------
more info: http://tlug.linux.or.jp                     Sponsor: PHT