This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Certainly not a typo in binuti
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Tristan,
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.
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.
Many VMS C codes written I have seen during Alpha to IA64 transition
have been developed and tested under the old VAXC standard on VAX/VMS
computers. For these users, the magic HP C/STANDARD=VAXC enables them
to upgrade to IA64 with the maximum of code portability. Separating
GNU compilers world and HP VMS compilers world would prevent many
users from a smooth transition even from the VMS to the Linux/Unix
worlds or vice-versa if applicable for them.
Yours truly,
Philippe
Le 31/03/2011 11:55, Tristan Gingold a écrit :
>
>
> On Mar 30, 2011, at 6:21 PM, Philippe Vouters wrote:
>
>> The VMS port of the Intel's assembler is freely downloadable by HP
>> partners but is only accessible by HP customers through their HP
>> partner. The HP OpenVMS group which ported this Intel's assembler
>> seems to have added the -Nvms_upcase option to it and when not
>> specified all global names are uppercased. This matches the default
>> behavior of all HP compilers.
>>
>> The GNU assembler on VMS processes global symbols as is. This matches
>> most GNU compilers default behavior, except gfortran which processes
>> all global names as lowercase characters adding a trailing underscore
>> unless -fno-underscoring option. The Adacore's GNAT Ada Pro product on
>> VMS product have an /UPPERCASE_EXTERNAL option to fit with HP
>> compilers generated code. I did not check calling GNAT Ada Pro VMS/Ada
>> code from HP Fortran for OpenVMS, focusing on this casing aspect. More
>> narrowing this casing problem, I did not check whether
>> /UPPERCASE_EXTERNAL also means /UPPERCASE_GLOBALS.
>>
>> A perhaps suggestion to the binutils GNU assembler developers would be
>> to add a VMS specific --uppercase-globals so that assembly routines
>> may be called from case insensitive HP compilers such as Cobol,
>> Fortran, Basic, Pascal or, when no /names=(as_is) added qualifier, by
>> the HP C and HP C++ compilers.
>
> Honestly I am a bit skeptical about this feature. The primary purpose
of gas is to
> assemble what gcc generates and IMHO uppercasing would better be done
by gcc.
>
> In particular uppercasing is somewhat ambiguous: should all symbols be
converted or
> only the exported one ?
>
> Tristan.
>
>
>
- --
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2UWWcACgkQsUYBDUbOpdqd9wCbBfraZi4YZiv1yw+1GhkjV1yt
n4AAoIfrZvvGfRscvvB5Dlx/yfgryocs
=OtWH
-----END PGP SIGNATURE-----