|
From: Tim S. <tim...@bi...> - 2011-04-22 17:42:24
|
On 04/22/2011 09:23 PM, John E. Malmberg wrote:
> Is there anyone else interested in VAX and ODS-2 name mangling support?
I'm interested in helping with this.
>
> For VAX, there are several additional issues needed to be resolved for
> having a useful port.
>
> 1. CC compiler does not support /FIRST_INCLUDE.
>
> This is an extremely useful feature for changing the way that a UNIX
> source module compiles with out editing the module.
>
> There are ways to work around this, such as using the + operator to
> concatenate source modules.
>
> Note that the older ALPHA Compilers also do not support this.
>
> 2. CC compiler does not support "long long" type.
>
> This may require source changes to affected modules.
>
I recently had issues with the 'long long' issue. However, I solved
this (and the /FIRST_INCLUDE issue) by using the GCC compiler. It
is old, a pain to organise. However, it does work and has been
generating fairly decent code for me.
> 3. CC compiler does not support /main=posix_exit.
>
> This requires either a source change or a /first_include file type hack.
>
The GCC equivalent has the /SCAN qualifier.
> Somewhere I may have a copy of a working GCC/VAX binary. This may allow
> working around the above issues. Unfortunately one source module for
> the last working GCC/VAX, the GCC.EXE wrapper is missing. The one that
> is supplied with the kit does not match the binary, and is not usable.
>
I have a kit that I built from this. I have since done a bit more
jiggery-pokery with a couple header files. However, 99% of what I
use it available here:
http://filesocial.com/39sfzk0
>
> 4. No support for IEEE floats. Not sure what that impact will be.
>
This one I don't know about either. I have a feeling that in most
cases it will not be too much of an issue. However, reading in
values from a file will require some sort of translation. This
might be a real pain. Something that I am looking at in my
project too.
>
> 5. No support for extended filenames.
>
> There are two encoding schemes, one is the TCPIP/NFS encoding using $
> characters followed by a code, which provides case sensitive and most
> popular extended characters, and the Pathworks/Advanced server encoding,
> which uses a double underscore followed by 2 hex digits for a wider
> range of characters.
>
> These encodings would be useful to have in gnutar, vmstar, zip, and
> such, and if they are put in a general purpose library, then they could
> be used by all utilities.
>
> 6. No mount points or symbolic links.
>
> This can be usually worked around one way or another.
>
> The GNV source code indicates that the mnt utility has been built on VAX
> in the past. I do not know if that means that it will be useful.
>
These last two points I'm not too sure about. I'd have to give it some
thought during the day time (it's pretty late here :-).
>
> And related to this is what versions of VMS would people want GNV or
> related utilities on?
>
I do all my work on V7.3. I don't know about other people's
situations, but I haven't seen an older version of VMS on
VAX (with the exception of hobbyist stuff) for at least 10
years.
Tim.
|