upgrading from GS160 to GS1280

[SAMI AHMAD]

do we need to recompile C programs going from GS160 to GS1280 ?
any thing we should be aware of in doing this transition or these systems are fully compatible?

thanks

[Ian Miller.]

Are you going to use the same version of VMS?

If so then should be fine. If not then, it will probably be fine.

There architectural differences between the GS160 and the GS1280 but nothing that would be noticed be the average application, apart from the speed improvement.

[Andy Bustamante]

>>do we need to recompile C programs going from GS160 to GS1280 ?

Answer is generally going to be no.

Please review the C User's Guide for the /ARCHITECTURE and /OPTIMIZE options. These allow the executable to be targeted for a specific architecture or built for a general "Alphaserver". Stepping up shouldn't be an issue, but you may gain something from building for the new architecture. The general answer "it depends" applies for your application.

Consider collecting before and after performance data with T4 or monitor.

Andy

[Colin Butcher]

Depending on the kind of processing your code is doing then recompiling with the GS1280 (EV7) specific /ARCHITECTURE and /OPTIMISE=TUNE values can make quite a big performance improvement to the way your code runs. The reason is that later implementations of the Alpha microprocessor have more instructions in the instruction set and if you tell the compiler to generate code using those instructions then you end up with better performance if the processing your application is doing can make extensive use of those kinds of instruction. See the Alpha Architecture reference for details.

Cheers, Colin (http://www.xdelta.co.uk).

[Robert Gezelter]

Sami,

I agree with Colin's comments. Binary images for older processors will run, albeit not at the highest efficiency. If the only processors in your inventory will be EV7 processors, then by all means recompile your program inventory.

A note is in order. Since the existing code will run properly on the newer processor, it is possible to disconnect the hardware replacement with the recompilation and requalificaton exercise.

As with all such performance questions, your mileage may vary (YMMV). The incremental performance increase of the added instructions depends on how significant they are in the overall mix.

- Bob Gezelter, http://www.rlgsc.com

[Willem Grooters]

As ususal: it depends.
In general: No. There are a few reasons that require your programs to be relinked, or recompiled, but these are quite specific. Relink may be required if your programs access system structures and you're migrating to a higher major OpenVMS version, but that would hold on a GS160 as well; the releasenotes would specify when needed.
Recompilation is required when your hardware accesses the system hardware directly; you may need to recode part of the code as well; but again: this is very, very specific, and hardly ever needed.
However, to get the best performance and efficiency, it would be a good idea to recompile. However, be sure to use a compiler that supports these new features; older compiler will not
Another issue to take in account if your programs contains timing controls: be prepared for timing issues, they may now run too fast. It may be required to re-tune these programs to behave within the limits.

[Hoff]

Sami, look at the C code in use at your site.

Do *you* think it'll upgrade?

You know this code best, after all.

Do you know if the code has been stable, and if the code was written with reliable synchronization techniques and with good OpenVMS coding practices, with the use of few or no undocumented interfaces, if the code compiles with no diagnostics and no warnings, and with few latent bugs?

If so, then the code will likely upgrade and port to the new AlphaServer with few problems. And you probably won't need to rebuild it.

If not, well, all bets are off. We don't know.

And if you're using executive- or kernel-mode in general here, then all bets are off.

Any discussion of architecture-specific instruction set generation from compilers is something that I'd consider a case of premature optimization. In this and similar cases, I'd recommend looking at the existing code with mechanisms such as CC /WARN=ENABLE=QUESTCODE and (if you have access to it) tools such as Clang, and at particularly at ensuring the existing code is solid and well written and documented and otherwise maintainable.

Once the code-base reached that state (or if the code is already there) and once your code-base is solid and maintainable and with good diagnostics and documentation and reproducible builds and reasonable regression test coverage, then techniques involving Alpha instruction set generation and particularly tools such as DECset Performance and Coverage Analyzer (PCA) are useful; finding and resolving hot-spots in the code.

In C and in OpenVMS in general (and this from very direct personal experience), it's very easy to have numerous latent bugs in apparently-working code. Upgrades and faster Alpha processors tend to expose these bugs. My first year or so of C code output on OpenVMS wasn't exactly the most stable of code around. Once you get the hang of regression testing and reproducible code-storage and code-building and diagnostics and error-checking and synchronization and SMP and such, it gets (much) easier.

As for your question, the classic computing joke comes to mind... In computing terminology, the word "compatible" actually means "different". If two widgets were actually identical, then they'd be called "identical". Not "compatible."

In general: there's no simple answer here. As with seemingly many responses posted recently, "it depends".