Porting of VAX C application to Alpha C

[Rajarshi Gupta]

Hi,
Can anyone please provide me the document or link for migrating the VAX C application to Alpha C. Any kind of information will be helpful like the trips to compile and linking the C codes of VAX to Alpha Open VMS environment.
Thanking You..

[Kris Clippeleyr]

Hi,

You'll find the necessary documents at
http://h71000.www7.hp.com/doc/porting.html

With most applications it's just:
1. transfer the sources
2. compile, link
3. test
4. go

Take special care with alignment of fields in structures.

Good luck,
Kris (aka Qkcl)

[ChaimBu]

Many moons ago I ported the local language versions of ALL-IN-1 and FMS (written in BLISS) from VAX to ALPHA, and the task was not nearly as difficult as I had expected!

Good luck !!!!!

Chaim

[Joseph Huber_1]

If the C on Vax was DECC, then no change should be necessary, except eventually some RTL routines may available on Alpha, but missing on VAX:
additional "#include <...>" may be necessary,
the compiler will tell if definitions are missing, or prototypes/definitions are conflicting with system includes.

If the Vax compiler was VAXC, then You will learn the difference to Ansi C. In a first attempt You can use CC/STANDARD=VAXC, but in the long term should eliminate all errors.

And of course, as Kris mentioned, be aware of data alignement: default on Vax is /NOMEMBER_ALIGNE, on Alpha natural alignement is default.
This should be no problem as long as the code does not assume a particular alignement (e.g. writing structures binary to files, or reading from a file into a structure).

[Martin Vorlaender]

Rajarshi,

we had a big application, developed on VAX VMS using VAX C, which we ported to OpenVMS Alpha with DEC C.

The MMS/COM files used for building worked (no surprise), but the DEC C compiler threw pages of warnings and errors - all of which we looked at, and corrected.

VAX C allowed for much sloppier programming, DEC C is much more picky (which IMHO is a good thing). You can get away with CC /STANDARD=VAXC , but if you ask me, you'd be better off to pay attention to every message the compiler generates (when run in ANSI mode).

HTH,
Martin

[Hoff]

The manual you're probably remembering was the VAX C to DEC C on OpenVMS VAX migration manual -- it was part of the DEC C for OpenVMS VAX manual set, and only the C manual set for VAX. (I know this had confused me.) Here's the right area, and the manual:

http://h71000.www7.hp.com/commercial/c/index_vax.html

There are additional OpenVMS manuals on migrating applications from VAX to Alpha around, look in the archived documentation area. Here's the archived area:

http://h71000.www7.hp.com/doc/archived.html

There's a newer porting manual which covers OpenVMS I64, that's in the main area for OpenVMS manuals.

http://h71000.www7.hp.com/doc/os83_index.html

There's a section on C coding on OpenVMS -- including common confusions and such -- in the OpenVMS FAQ. Pull over the text or PDF edition and search it, and you'll find discussions of string descriptors in C, and of C architecture-specific compilation qualifiers and such:

http://www.hoffmanlabs.com/vmsfaq/

There's a list of common coding bugs in the old OpenVMS Ask The Wizard (ATW) area, and specifically here:

http://h71000.www7.hp.com/wizard/wiz_1661.html

Don't assume that the volume of available documentation implies and correlates to the degree of difficulty involved. This port is usually pretty easy, though the newer C compilers will tend to find and report any weak(er) or buggy areas of the existing C code. In many cases I've encountered, these reports are outright bugs, bugs that have been latent in the application for some time.

Stephen Hoffman
HoffmanLabs

[Stanley F Quayle]

You might have to add Memory Barrier [DEC C built-in _MB()] if you're using global sections. This causes changes in the global section to be visible to other processes. There's no such construct on VAX, since the memory management hardware took care of it...

[Hoff]

The following is building on what Stanley commented on, and applying to applications that implement shared memory.

Here are some details on memory barriers:

http://h71000.www7.hp.com/wizard/wiz_2681.html

VAX did have memory consistency requirements around multiprocessor interlocking, around the instruction stream, and around word tearing, though Alpha pushed this whole area much more aggressively.

Another consideration here is processor interlocking. That's in addition to the memory barriers. (Similar interlocking rules were present on VAX SMP systems.) When you have shared memory, you need to coordinate access not only out into the arrays, but across the processor caches, as MB isn't enough -- MB gets the data out into the memory, but doesn't pull it into visibility across the other processors in an SMP box.

http://h71000.www7.hp.com/wizard/wiz_6984.html

The bitlocks and interlocked queues and interlocked add operations combine the memory cache coherency of the memory barrier operations with interlocked capabilities available across multiple processors; for queues. Either the process gets or releases the lock, or it gets blocked, or it gets a lock error. The process can't get rescheduled in the middle of the sequence, etc.

If you're not using shared memory and not working on a driver, you can pretty much ignore this whole area. But -- much like VAX before it -- if you're sharing memory on Alpha and particularly on an SMP Alpha, you have to manage your critical operations within the shared memory region with some care.

Over the years and save for work within device drivers and such, I very seldom end up needing and using the memory barriers. (But when you need the MB, you really need the MB.) More commonly, I end up using the interlocked operations.

[Jan van den Ende]

Rajarshi,

from your Forum Profile:


I have assigned points to 37 of 89 responses to my questions.

Several of thr threads with unassigned answers date back to 2005.

Maybe you can find some time to do some assigning?

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption "My Question(s)" you will find "questions or topics with unassigned points " Clicking that will give all, and only, your questions that still have unassigned postings.
If you have closed some of those streams, you must "Reopen" them to "Submit points". (After which you can "Close" again)

Thanks on behalf of your Forum colleagues.

PS. - nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before - please do not take offence - none is intended!

PPS. - Zero points for this.

Proost.

Have one on me.

jpe