Porting C Code VAX -> Alpha -> IA64

Porting C Code VAX -> Alpha -> IA64

Post by Code Monke » Thu, 03 Jul 2003 07:37:31



Currently have an application compiling under DEC C v.5.7 on VAX using the
following compiler symbol;

    CC/STANDARD=VAXC/EXTERN_MODEL=COMMON_BLOCK/SHARE_GLOBALS

Would like to port this to Alpha eventually, and would like to know if there
are any
disadvantages to keeping this compiler symbol on the Alpha platform.

Will the Alpha Compaq C compiler generate code as efficiently as it can with
this symbol ? Or to unlock it's true potential should it be changed ?

Would ideally like to change this to the default standard (which I believe
it RELAXED_ANSI), but would need to be able to justify such a move...... as
I'm
sure more tweaking to the code would be required.

Also does anybody know if the OpenVMS C Compiler on Itanium will have the
/STANDARD=VAXC option in it ??

If not then I see the above move as a prerequisite to porting to IA64
further on down the road.

Your comments and suggestions are greatly appreciated.

 
 
 

Porting C Code VAX -> Alpha -> IA64

Post by Phillip Helbi » Thu, 03 Jul 2003 17:35:15


Quote:>     CC/STANDARD=VAXC/EXTERN_MODEL=COMMON_BLOCK/SHARE_GLOBALS

Standard=VAXC is almost an oxymoron.  :-)

Even if this option will be supported on Itanium, I would recommend
fixing everything which breaks if you don't use it.

To be fair, the VAX compiler predates the '89 C standard.  Somewhere on
the net you can find an article by Dennis Ritchie (probably there's a
link from his home page) in which he praises the quality of the (first)
VAX C compiler.

 
 
 

Porting C Code VAX -> Alpha -> IA64

Post by Ed Voge » Thu, 03 Jul 2003 23:17:26



| | Will the Alpha Compaq C compiler generate code as efficiently as it can
with
| this symbol ? Or to unlock it's true potential should it be changed ?
|

    No.  There are some optimizations that the compiler would do when
/STAND=RELAXED
    is specified that it does not do when /STAND=VAXC is specified.

    However, sometimes turning on these optimizations breaks code that
relied on a VAX C
    behavior (this is why the optimization is turned off when /STAND=VAXC is
specified).

| | Also does anybody know if the OpenVMS C Compiler on Itanium will have
the
| /STANDARD=VAXC option in it ??

    The goal for the C compiler on Itanium is "recompile and go".  The
/STAND=VAXC qualifier
    will be supported there.

    Ed Vogel
    HP C for OpenVMS Engineering

 
 
 

Porting C Code VAX -> Alpha -> IA64

Post by Thomas Dicke » Thu, 03 Jul 2003 23:10:19



>>     CC/STANDARD=VAXC/EXTERN_MODEL=COMMON_BLOCK/SHARE_GLOBALS
> Standard=VAXC is almost an oxymoron.  :-)
> Even if this option will be supported on Itanium, I would recommend
> fixing everything which breaks if you don't use it.
> To be fair, the VAX compiler predates the '89 C standard.  Somewhere on
> the net you can find an article by Dennis Ritchie (probably there's a
> link from his home page) in which he praises the quality of the (first)
> VAX C compiler.

otoh, it did not care if one added spurious &'s before arrays
(that was fixed in a later version, but caused me some confusion)

--

http://dickey.his.com
ftp://dickey.his.com

 
 
 

1. >>>update: DECC: problem porting VAX->AXP, fopen remote mbx

Hi all!

First, thanks to all who answered my first post!

Unfortunatly, I still haven't found the reason why
this DEC C program behaves correctly on a VAX
(DEC C V5.0-003 on OpenVMS VAX V6.2), but
not on an AXP (DEC C V5.3-006 on OpenVMS Alpha V6.1).

I am re-posting it, adding the additional insight
gathered based on the responses so far.

#include stdio                                          
#include errno

main()
{
FILE *f;

        f = fopen("NODE::MAILBOX:","w");
        if (f == NULL) {
                perror("fopen fail");
                return;
        }
        printf("one\n");
        fclose(f);

Running it on the AXP returns this message:

fopen fail:
non-translatable vms error code: 0x144, vms message:
%system-f-ivdevnam, invalid device name

How can it become an ivalid device name when it
is a correct one on the VAX???

I circumvented the problem by spawning a subprocess
and writing into the remote mailbox using a DCL
command procedure. This, to my understanding, rules
out any proxy related problems.

The NETSERVER.LOG log file created on the remote end
does not contain any more information pointing to the
soruce of the problem. It just registers the connection
request.

The only advice gotten in previous post I haven't been able
to follow so far is to apply the decc rtl patches.
Maybe this will help or maybe somebody can shed more
light on this strange affair.

        -- ChrisW

CHRIS J.   Swiss News Agency (SDA/ATS), Laenggass 7, CH-3001 Bern, Switzerland
WALTHER    voice: +41 (31) 309 3456/3333 -- FAX: +41 (31) 302 8238

"The road to the future is always under construction"
                                          Graffiti in a Port Elizabeth township

2. mpg123 PITA

3. MAIL >> SEND >> MAILER!<......> to other networks via WISCVM?

4. Need Intel 188EC Transmuter

5. Telnetting to VMS VAX -> VAX or VAX -> ALPHA ?!?

6. How to force recursive queries?

7. >>>>WIZARD>>> How do read VAX/VMS files on a PC <<<WIZARD<<<<

8. D-Link CF 56K Modem and the TRGpro, Need a clue here.

9. <<>> COMPUTER SOFTWARE / HARDWARE <<>>

10. CMS >>> Alpha CMS (Again...)

11. SMTP->VMS->POP->Eudora->MIME and QP

12. Digital/VAX -> DECmailworks -> Teamlinks -> Mac

13. Newswatchers with Mac-->VAX-->>USENET server