This is the mail archive of the
mailing list for the binutils project.
Re: Certainly not a typo in binuti
- From: Tristan Gingold <gingold at adacore dot com>
- To: Philippe Vouters <philippe dot vouters at laposte dot net>
- Cc: binutils at sourceware dot org, Office of OpenVMS Programs <OpenVMS dot Programs at hp dot com>
- Date: Fri, 1 Apr 2011 09:49:57 +0200
- Subject: Re: Certainly not a typo in binuti
- References: <4D931F4D.firstname.lastname@example.org> <E3EBFF27-2CEE-4B81-8B55-CD87E51CE072@adacore.com> <4D935897.email@example.com> <90BB3DA8-CE4B-4AF4-9F41-3A3E97D8A9D5@adacore.com> <4D945972.firstname.lastname@example.org>
On Mar 31, 2011, at 12:37 PM, Philippe Vouters wrote:
> I do understand your doubtfullness. The GNU assembler is primarily
> designed for the GNU compilers. However, why excluding most HP VMS
> compilers customers from using gas and force them to use the Intel's
> proprietary assembler they can't freely get it by their own ?
> Currently gas can only used by HP C and C++ compilers users only when
> they add the /names=(as_is) option to their compile command. This
> eliminates all HP VMS Cobol, Fortran, Pascal, Basic customers from
> using gas.
> As I wrote, this can be avoided if gas implements a special
> - --uppercase-globals option intended to VMS users which would uppercase
> all exported symbols from within an assembly code. This way all HP VMS
> compilers customers could mix their code with the gas assembler.
Well, if you speak about hand-written assembly code, you can simply modify the
If you speak about compiler generated assembly code, doing this in the assembly
is not enough and you'd better to deal with that in the compiler itself.
There are many cases to consider such as converting well known function names (such as
the one from the C library) to the VMS convention (ie open -> DECC$OPEN).
> As HP Fortran implements 77, 90, 95 standards and GNU Fortran
> implements 90, 95, 2003, 2008 and gnu standards along with the so
> appreciated OpenMP directives, it would also be imaginable that VMS
> Fortran users could write new codes using gfortran that they mix with
> their HP Fortran 77, 90, 95 already tested codes. So when and if
> gfortran is ported to the VMS world, it should also include such a
> - --uppercase-globals option in combination with -fno-underscoring.
Feel free to submit a patch to implement this feature.