OpenVMS Notes: "VAX to Alpha" Porting Diaries

Note: this page has become lengthy, in an attempt to document everything that I encountered (so that other poor devils won't have to do the same). To a non-programmer it may look like porting from VAX to Alpha might not be worth the trouble, but nothing could be further from the truth. This conversion was much easier than my usual programming duties and was mostly done in my spare time up to, and including, Christmas through to Y2K. Overall, I'm very impressed with Alpha technology. It requires much less electricity than VAX; it does not require any special air conditioning or power; it is priced much lower than VAX while offering much higher performance.
edit: 2015-06-20 what: chopped out some crud)

Porting Diary #1 (1999-Nov to 2000-Jan)

Week 1 (My first Alpha...)

Our "skunk works in Waterloo" has just (1999-11-30) received an AlphaServer 4100 (with DUNIX 4.1 installed) from a cancelled project and we've been commissioned to port a relatively large business application (consisting of ~ 200 VMS programs) from a dual VAX-8550 cluster to Alpha.

This specific machine is an AlphaServer 4100 5/300 which was manufactured in 1996. It contained a single 21164 (EV5) CPU running at 300 MHz with 2 MB of cache and 256 MB of RAM. Five modules can be installed in the CPU chassis (one for the PCI/EISA interconnect and four for CPU's). Because of the clock speed I thought this machine might be a bit of a dog but it "seems" much faster than my VAX-6430 (at least it boots up five times faster). I always have to remind myself that these pipelined super scalar 64-bit RISC CPUs are usually more powerful than they first seem.

• Click here to see where the 21164 (EV5) is located on the Alpha family tree
• Click here to view a "VAX vs. Alpha CPU" chart as well as some charts comparing VAX and Alpha performance in units called PERFs (I guess they don't use VUPs any more).

The disk subsystem is based upon MYLEX configurable RAID controllers which connect to five "storage works" arrays (each filled with six 4-GB SCSI drives). Since all RAID functions are handled in hardware, the CPU can pay more attention to running the OS and apps. The controller can be modified with a configuration program to support RAID #1 (mirroring), RAID #0 (striping), RAID 0+1 (a.k.a. RAID #10) and RAID #5 (complete multiple disk redundancy). Note that we chose "RAID 0+1" since this method provides that will tolerate multi-drive failure in a single raid-set.

All the chassis boards (except CPU and memory) are either PCI or EISA based so these machines are considerably less expensive than the VAXs they are about to replace.

Week 2 (We get the CD-ROMs)

We ordered the complete "OpenVMS for Alpha" software distribution library (24 CD-ROMS for just under $1K Canadian) so we'll be prepared when we receive our temporary licenses from Compaq/HP.

(this activity was due to a misunderstanding on our part; apparently ROMs would have been provided free of charge; oops!)

Week 3 (We borrow licenses)

We received our software distribution library this week so we placed a call to Compaq/HP to acquire some temporary licenses (good for 60 days) through their Software Loan program. We ordered licenses for the following:

• OpenVMS 7.2-1
• DEC-BASIC
  • our applications were written using VAX-BASIC because this was one of the languages that offered "built in" ISAM support
• TCP/IP (UCX) Services for OpenVMS
  • so visitors from other parts of the company can check out the compiler and help test the ported applications etc.
• DECnet services
  • so we can copy indexed RMS (Records Management System) files from our old VAX to the new Alpha
• Forms Management System (FMS) - developer version
  • our VAX-BASIC applications were written with FMS calls; Compaq/HP suggests using DECforms for new program development

Week 4 (The fun begins...)

We received our temporary licenses and started to install the new software as follows:

1. upgraded the AlphaBIOS console firmware from 4.0 to 5.3, and then to 5.5
   Notes: this two step upgrade is recommended by Compaq/HP in their OpenVMS Alpha Installation Manual which is part of their dual format (Windows or OpenVMS) "OpenVMS Version 7.2 Documentation CD-ROM". The firmware CD-ROM came with the OpenVMS binary CD-ROM.
2. installed OpenVMS 7.2-1
3. installed the previously mentioned layered products. They installed and verified so quickly that it's scary.
   This machine can completely boot OpenVMS then start DECnet and TCP/IP in under two minutes!
   • DECnet Phase IV looks the same on Alpha but seems much faster.
     • Since my preliminary tests only involved copying files to the Alpha, this speed improvement may be due to the RAID subsystem.
   • FMS looks the same on Alpha
   • Searching large (40K line) programs with the EDT editor is unbelievably fast. Saving changes is even faster.
   • Linking is unbelievably fast
   • Indexed RMS files copied from VAX to Alpha via DECnet can be accessed by DEC-BASIC programs without modification.
     • Note: OpenVMS on Alpha still uses the tried-and-true FILES-11 disk format
   • I had never used Compaq's version of TCP/IP (a.k.a. UCX) but it installed easily on Alpha.
     • UNIX people used to making quick edits of the host file may be surprised to find that that this can only be done by a "DECnet NCP" style interface (e.g. "set host name" adds the entry to "host")
   • DEC-BASIC is a little different from VAX-BASIC
     • no interpreter mode (no loss there)
     • neat optimizer to really show why RISC is better than CISC

Week 4a (VAX-BASIC 3.8 to DEC-BASIC 1.3)

note: DEC-BASIC has been renamed Compaq-BASIC for OpenVMS (and now HP-BASIC for OpenVMS)

• Compiling large (40K line) programs takes an unbelievable amount of resources and time. The release notes state that this is due to the optimizer which defaults to the highest setting of 4.

• the developer's process needed to have /PGFLQUO set to 500,000
• compiling was faster with /WSEXT set to 100,000
• the compiler defaults to /OPTIMIZE=LEVEL=4 which returns some VERY interesting informational messages about source code quality but takes a real long time depending on how many other people are logged in
• when /OPTIMIZE=LEVEL=1 was used, compile time dropped to 21 minutes.
• when /OPTIMIZE=LEVEL=0 was used, compile time dropped to 14 minutes
• Since the same program would compile in 4 minutes using VAX-BASIC on a VAX-6430 (32-bit CISC), I can only imagine what the compiler now has to do when generating instructions for a pipelined super scalar 64-bit RISC
• after linking, the resulting executable was more than twice the size of the VAX equivalent (this is to be expected when moving from CISC to RISC)

• Compiling small (< 5K line) programs is faster on Alpha than VAX when optimization is disabled
• Almost all programs compiled with VAX-BASIC also compile with DEC-BASIC except for a few little caveats
• make sure you convert all HFLOAT declarations to either DOUBLE or GFLOAT because HFLOAT is not available on Alpha. (DOUBLE offers 3 more bits of precision while GFLOAT allows a larger mantissa)
• the following VAX-BASIC 3.8 program will not compile under DEC-BASIC 1.3 (you'll get a duplicate line number error at line 30010):

1000	option type=explicit
	external long function funct1(long, long)
	external long function funct2(long, long, long)
	print funct1(1%,2%)
	print funct2(1%,2%,3%)
30000	end
30010	%include "funct1.fun"	!
30020	%include "funct2.fun"	!

• the following modified program will compile under DEC-BASIC 1.3:

1000	option type=explicit
	external long function funct1(long, long)
	external long function funct2(long, long, long)
	print funct1(1%,2%)
	print funct2(1%,2%,3%)
30000	end
30010	%include "funct1.fun"	!
	! <--- need some text between included functions
30020	%include "funct2.fun"	!

• the following VAX-BASIC 3.8 program will not compile under DEC-BASIC 1.3 (you'll get a "line numbers out of order" error message):

1000	option type=explicit
	external long function funct1(long, long)
	external long function funct2(long, long, long)
	print funct1(1%,2%)
	print funct2(1%,2%,3%)
30000	end
100	%include "funct1.fun"
	!
200	%include "funct2.fun"

So just modify the line numbers to be somewhere between 30001 and 32767.

• A program that calls "sys$crmpsc" (and another that calls "sys$mgblsc") to set up a memory area for "inter process communication" runs on the VAX but will not run on the Alpha. To fix these calls so that they will work properly on both platforms, you must do four things:

1. call "sys$getsyi" with a "syi$_page_size" request. VAX is always 512 but Alpha can be any multiple of 8192 (depends on the individual machine).
   Notes:
   1. Use this data to "boundary align" the addresses in the first quadword passed in the call
   2. Don't use this data to "compute the number of pages requested" since the system call expects 512 byte pagelets
       
2. The starting address must be pushed down to the lower page boundary. For example, it the page size is 8192:
   address1 = (address1 and -8192) which clears lower order bits
   Note: this is not necessary if the area to be mapped is in a COMMON AND the COMMON is page aligned in memory via the LINK /OPTION command (where an option file specifies the common name in a PSECT with a PAGE align directive)
    
3. The ending address must be pushed up to the upper page boundary. For example, if the page size is 8192:
   address2 = (address2 or (8192-1)) which sets lower order bits
    
4. compute the number of requested pagelets:
   pages = (address2 - address1 + 1) / 512
   
   Note: the preceding fix is not necessary if you map to the section using the "SEC$M_EXPREG" flag

Week5 (BASIC code renovation) - We're still having fun, right?

 Note: you should renovate your code in this way whether you intend to port or not

Program Renovation: Our currently semi-formal method of declaring external functions has made me question whether porting programs "as-is" to a new hardware architecture will always be safe. Everything has worked properly so far but I keep thinking there is room for improvement. After receiving some suggestions from Francois Daigneault in Montreal, I've decided to change to a more formal coding method. Three program examples follow (blank lines have been removed to save space on this page):

• This method is the least formal.
• Danger: If you accidentally use a "32-bit long" instead of a "64-bit quad" in the sys$bintim system call, no compile time error will be seen. The system call will work properly but will overwrite the next variable causing unpredictable results.

1000	!
	! informal example (we never do this but I have seen others who have)
	!
	option type=explicit
	record QuadWord
		long long0
		long long1
	end record
	external long function sys$bintim	! informal (no inbound parameter list)
	declare QuadWord QuadBuff
	call sys$bintime("0 ::15", QuadBuff)	! compute delta time 15 seconds from now
30000	end

• This method is mediocre.
• The compiler will pick up any declared "data type" or "passing mechanism" errors. The problem here is that every external function needs to be declared by the programmer (who many times may not have had enough coffee or sleep). You can save time by putting all often used externals in an "include file" but you're in trouble if Compaq/HP decides to make a change to their published documentation. You are also in trouble if you move your code to another platform (like Alpha or Itanium)

1000	!
	! semi-formal example (our current coding practice)
	!
	option type=explicit
	record QuadWord
		long long0
		long long1
	end record
	external long function sys$bintim (string by desc, QuadWord by ref)	! semi-formal
	declare QuadWord QuadBuff
	call sys$bintime("0 ::15", QuadBuff)	! compute delta time 15 seconds from now
30000	end

• This method is the best way. All externals come from vendor-supplied text library "sys$library:starlet$basic.tlb". Also note that this library creates a Basic$QuadWord data type which we must use in the system call to keep the compiler happy. If you have a special condition that requires passing a customer data type, set up a record with a "variant clause" which will overlay a quad type over the custom type.

1000	!
	! formal example (what we will change to)
	!
	option type=explicit
	%include "starlet" %from %library "sys$library:starlet$basic.tlb"	! system services (formal)
	declare Basic$QuadWord QuadBuff
	call sys$bintime("0 ::15", QuadBuff)	! compute delta time 15 seconds from now
30000	end

• If you need external constants like SS$_Normal, just add another %include statement to pull in that book from the library. For example:

	%include "starlet"	%from %library "sys$library:starlet$basic.tlb"	!system services
	%include "$ssdef" 	%from %library "sys$library:starlet$basic.tlb"	!ss$ definitions
	%include "$syidef"	%from %library "sys$library:starlet$basic.tlb"	!syi$ definitions
	%include "$jpidef"	%from %library "sys$library:starlet$basic.tlb"	!jpi$ definitions
	%include "lib$routines"	%from %library "sys$library:starlet$basic.tlb"	!lib$ RTL

• To view the books in the library, execute the following DCL command:

$libr/list sys$library:starlet$basic.tlb

• To produce a searchable text file version(s) of the library, execute one of the following DCL commands:

$libr/extract=starlet      sys$library:starlet$basic.tlb ! we only want book "starlet" (sys$qiow, etc.)
$libr/extract=lib$routines sys$library:starlet$basic.tlb ! we only want book "lib$routines"
$libr/extract=*            sys$library:starlet$basic.tlb ! we want to view the whole library (~5800 blocks)

Week 5a - My "renovation plan" reality check...

• The Problem...
  I've just discovered a bug in module LIB$ROUTINES from library SYS$LIBRARY:BASIC$STARLET.TLB which affects both VAX-BASIC and DEC-BASIC up to, and including, OpenVMS 7.2-1 . This only affects routines LIB$BBCCI and LIB$BBSSI. I've proved to my satisfaction that the published documentation does not exactly match the declarations found in STARLET (see: hacking starlet). A demo follows.

1000    option type=explicit
	!
	%let %method=2
	%if %method=1
	%then
	  ! this new method crashes at run time
	  %include "lib$routines" %from %library "sys$library:basic$starlet.tlb"
	%else
	  ! this old method runs properly at run time and matches published documentation
	  external long function lib$bbcci( long by ref, any by ref)	! from VMS documentation
	  external long function lib$bbssi( long by ref, any by ref)	! from VMS documentation
	%end %if
	!
	! the following stub was adapted from a FORTRAN example found in document:
	!	"OpenVMS RTL Library (LIB$) Manual"
	!
	common(abc)long        states(4)	! could be shared memory
	!
	print "doing set of clear bit"
	if (LIB$BBSSI (42, states())) then
	    print 'State bit 42 was previously set (oops)'
	else
	    print 'State bit 42 was clear'
	end if
	!
	print "doing clear of set bit"
	if (LIB$BBCCI (42, states())) then
	    print 'State bit 42 was set'
	else
	    print 'State bit 42 was previously clear (oops)'
	end if
30000	end

• The Fix...
  In January 2000, I discussed my problem with Compaq and was told it was a documentation error associated with OpenVMS-7.2-1 (since BASIC$STARLET is automatically generated internally from other internal procedures like SDL, Compaq was not about to change it).
  
  follow up note: Compaq released new documentation around the time they released OpenVMS-7.3-1
  
  The new documentation states that the second parameter is an address passed by value (yes, you read that correctly) so the fix requires us to use the BASIC LOC() function to determine the address and then let the compiler use the "library declared" passing mechanism:

1000    option type=explicit
	%include "lib$routines" %from %library "sys$library:basic$starlet.tlb"
	!
	common(abc)long        states(4)	! could be shared memory
	!
	print "doing set of clear bit"
	if (LIB$BBSSI (42, loc(states()))) then ! address passed by value (not variable passed by reference) 
	    print 'State bit 42 was previously set (oops)'
	else
	    print 'State bit 42 was clear'
	end if
	!
	print "doing clear of set bit"
	if (LIB$BBCCI (42, loc(states()))) then ! address passed by value (not variable passed by reference)
	    print 'State bit 42 was set'
	else
	    print 'State bit 42 was previously clear (oops)'
	end if
30000	end

Compiler Optimizer Fun

Dealing With Unused code:

• When variables aren't used, program lines that access them are removed by the optimizer (doesn't affect your source code).
• If the following example is compiled with optimize level 1 or higher, no run time error occurs because the compiler "knows" that the variables are never used so the generating lines are discarded.

  1000	option type=explicit
  	declare long a,b,c
  	a = 4 + 5	! optimizer removes this second pass (a is never used after next line is removed)
  	b = a / 0	! optimizer removes this on the first pass (b is never accessed)
  30000	end

• In this example a run time error occurs when variable "a" is divided by zero.
  

  1000	option type=explicit
  	declare long a,b,c
  	a = 4 + 5
  	b = a / 0
  	print b		! this reference blocks code removal by the optimizer
  30000	end

Detecting Non-sense Code:

• In this example the compiler realizes that appending a character onto a fixed length string will produce no result. This stub was found in a working program! I'm not sure why "optimizer level 1" doesn't produce an informational and the print statement was added just to make sure the optimizer wasn't removing code.

<sr> $
<ur> type pos_demo.bas
<sr> 1000	option type=explicit				!
		map(abc) string dev_name$ = 8			! fixed length string
		dev_name$ = "LTA9999"				! insert 7 characters
		if pos(dev_name$,":",1%)>0% then		! if a colon was found here
		    dev_name$ = dev_name$ +":"			! then append a colon (problem line)
     !~~~	    dev_name$ = edit$(dev_name$,128%) +":"	x what the programmer meant
		end if						!
		print dev_name$					!
     30000	end						!
     $
<ur> bas/optim=level=0/warn=all pos_demo
<sr>	
	dev_name$ = dev_name$ +":"
	^
	%BASIC-I-EXPNOTRES, expression does not contribute to result
	at line number 5 in file DKB0:[NEIL]POS_DEMO.BAS;4
     $
<ur> bas/optim=level=1/warn=all pos_demo
<sr> $								! no informational

More Non-sense Code

• In this example the informational is only seen when the optimizer is on.
  note: since expression "order of precedence" indicates that AND will be evaluated after <>, the DEC-BASIC compiler has detected something we didn't intend.

<sr> $
<ur> type logic_demo.bas
<sr> 1000	option type=explicit
		declare long rc%
		! rc% = sys$qiow(bla...)
     !~~~	if (rc% and 1%) <> 1% then		! <-- what was intended
		if rc% and 1% <> 1% then		! <-- what was entered
		    print "error: ";rc%
		end if
     30000	end
     $
<ur> bas/optim=level=0/warn=all logic_demo 		! <-- produces no messages
<sr> $							!
<ur> bas/optim=level=1/warn=all logic_demo		! <-- produces messages
<sr>
	if rc% and 1% <> 1% then
	^
	%BASIC-I-UNREACH, code can never be executed at label 
	at line number 5 in file DKB0:[NEIL]LOGIC_DEMO.BAS;2
     $

Week6 (VAX-C to DEC-C )

(note: DEC-C has been renamed Compaq-C; and now HP-C)

More Program Renovation

1. I have just discovered that approximately 5% of our binaries have been written in VAX-C 3.2 which is a product that Digital replaced with DEC-C 4.0 (for VAX and Alpha) in the early 1990's and has been recently renamed to Compaq-C 6.2
    
2. We contacted Compaq/HP to get a temporary license for DEC-C 6.2 and installed it with no problems.
    
3. Compiling the old "VAX-C" source code with the new compiler is another story. Even though we compiled with switch "/STANDARD=VAXC" we observed many error, warning and informational messages. At this point it seems that the reason for this problem is the poor quality of the legacy source code.

• the legacy authors had quite a bit of code that tested for a return value of -1 from C functions "fwrite" and "fread". The compiler humorously informed us that "this may not be what you intended". (we are amazed that the program seemed to work properly for the last 7 years; just luck I guess...)
  
  We changed the -1 reference to 0 as per the DEC-C-RTL documentation
   
• the legacy authors had created many functions of type "int" but had not returned any values.
  
  We solved this problem by redeclaring these functions as type "void"
  
• the legacy authors had enabled access to the VAX instruction set with statement "#pragma builtins" and then referenced _MOVC3 over 60 times to copy data to (and from) an OpenVMS "global section" which was being used for IPC (inter process communication). Since _MOVC3 is not available on the Alpha, these references would not compile properly.
  
  We solved this problem by writing a macro to redefine _MOVC3 as a call to function "memcpy" (these lines should actually be renovated so the program remains OpenVMS portable)
  
• the legacy authors had many programs where functions had not been prototyped which caused quite a few compiler messages. (how where these programs originally compiled? With /STANDARD=NONE perhaps?)
  
  We solved this problem by properly prototyping the functions before they were referenced
  
• the legacy authors called "sys$crmpsc" and "sys$mgblsc" in a unique way that is different than the BASIC example above so renovation is probably not required. However, I think the _ALIGN(OCTAWORD) statement which precedes the variable declarations which get mapped into the "global section" may need to change to __ALIGN(PAGE)
  
• the legacy authors was also accessing VAX instructions _MOVC5 and _LOCC which are not available on the Alpha.
  
  Although _MOVC5 can be replaced with two calls to "memcpy", and _LOCC can be replaced with a call to "memchr", we were able to replace these VAX calls with renovated code that doesn't require them.

 Recently Discovered Online "C" Documentation

• HP C For OpenVMS (DECC) Language Home Page
• VAXC to DECC Migration Guide for VAX (contains valuable info for people needing to renovate while porting to Alpha)
• Click RISCy C/C++ Code to read a DECUS article discussing problems that might arise when writing C/C++ programs for RISC architectures

 Mid Week Summary

Despite the fact that many system calls were done in both VAX-BASIC and VAX-C, it has been much easier to port BASIC than "C". This seems a little strange to me since "C" is considered the favorite porting tool of industry. Perhaps things would have gone a bit better if our "C" source code had been kept up to date with newer versions of the DEC-C compiler which had been available on VAX for a least 7 years. On a different note, I now believe that porting COBOL and FORTRAN apps would probably be just as easy as porting BASIC.

Tomorrow I'll attempt to recompile the DEC-C programs with switches "/STANDARD=PORTABLE" and "/STANDARD=MIA" just to see what kind of compiler messages are produced.

more to follow...

Executive Summary (port 1)

• starts with a trial port of two large VAX-BASIC apps (with system calls sys$crmpsc and sys$mgblsc) previously running under VMS 6.2 (dorking around with these new calls took up more time then I expected)
• finished with a port of ~200  VAX-BASIC apps and ~10 VAX-C apps previously running under VMS 5.5-2
• more time than usual was spent renovating VAX-C programs to run under DEC-C (if ongoing code maintenance had been done on these apps then this wouldn't have been necessary)
• total conversion time was one person working ~ 8 weeks in my spare time
• porting verification required two people ~ 2 weeks in our spare time (since the code worked almost the first time after minor renovation, many tests only involved automated stress tests) 

Miscellaneous Stuff #1 (Public Relations)

• So far, this "VAX to Alpha" port has been simpler than we first imagined and is more of a transfer than port. I'm certain this has much more to do with OpenVMS engineering than any skills that I may have. Kudos to Compaq/HP
• Paul Mifsud of HP Canada (Markham, Ontario, Canada) has been very helpful and prompt in supporting us. Thank you Paul.
• Many people believe that Alpha systems are more expensive than the VAXs they are about to replace. Alphas are actually much less expensive. Remember that the VAX architecture was totally designed and manufactured by Digital while the Alpha architecture is based on industry standard components like PCI boards and SCSI drives. If you don't believe me then down load Compaq's Windows-based Alpha Configuration Utility and check for yourself. (Oops. The ACU is no longer available. Try this new tool: HP Configurator)
  • select "Express SERVER"
  • select "OpenVMS" (this is a two user base license)
  • select "Cabinet"
  • select "DS20E" (this is a departmental class system)
  • select "ES40 Model 1"
  • select 1000 MB of memory (yes; one gig of SDRAM)
  • select 100 Gig of disk storage
  • select 2 CPUs
  • select RAID Disk/Tape connection
  • click "Configure"
  • resultant price calcs as of 2001-04-25

    System	CPU(s)	Price (US$)
    DS20E 500	2 x 500 MHz	53k
    DS20E 667	2 x 667 MHz	59k
    ES40 500 Model 1	2 x 500 MHz	68k
    ES40 667 Model 1	2 x 667 MHz	70k
    ES40 883 Model 1	2 x 883 MHz	85k

Miscellaneous Stuff #2 (Technical)

TOOLS

some free Alpha Migration Tools (AMT) including:

• DECmigrate for OpenVMS Alpha migrates OpenVMS VAX applications to OpenVMS Alpha.

• DECmigrate for DIGITAL UNIX migrates ULTRIX RISC applications from MIPS to Compaq's Tru64 UNIX on Alpha
  note: DECmigrate has been renamed OpenVMS Migration Software for VAX to Alpha (a.k.a. OMSVA)

both these tools perform a binary translation so would only be useful if you don't have your original source code (a scary thought...)

MACRO-64

I've just discovered a neat little migration tool. From OpenVMS Alpha you can execute the DCL command $Macro/migrate to read a 32-bit VAX MACRO source file (.MAR) but generate a 64-bit Alpha object file. You do not need a license to do this.

However, you do need a license to execute the DCL command $Macro/alpha which reads an Alpha MACRO-64 source file (.M64) and generates a 64-bit Alpha object file. This is strange since the MACRO assembler was previously free with OpenVMS on VAX as well as RT-11 and RSX-11M on PDP.

Update: MACRO-64 is a layered product that can still be found on the latest (Alpha OpenVMS 7.2-1) consolidated software distribution CD-ROMs and requires a license to run. However, if you phone Compaq to purchase a license they won't be able to find it on their price list because this product is now freeware; it's just that they (Compaq) haven't yet done a good job promoting this fact. Anyway, here is the required license information courtesy Compaq:

$ LICENSE REGISTER MACRO64 -
	/ISSUER=DEC -
	/AUTHORIZATION=OPENVMSFREEWARE -
	/PRODUCER=DEC -
	/UNITS=0 -
	/ACTIVITY=CONSTANT=100 -
	/CHECKSUM=2-JHNL-LJEJ-CIMA-DOOI
$ LICENSE LOAD MACRO64

Click http://h41379.www4.hpe.com/openvms/freeware/index.html if you don't have the access to the consolidated software distribution CD-ROMs.

DEC-BASIC Compiler Benchmarks

• The following test compiles were done on my AlphaServer 4100 which contains a single 21164 (EV5) CPU running at 300 MHz. with a 2MB cache and 256 MB of RAM. Listing was enabled and no other interactive or batch processes were running. I'm sure that newer machines would run faster and later generation Alpha CPUs would be capable of more sophisticated optimizations.

• The following results came from a compile of a 2400 line program with 5 external functions and many system calls.

  Optimizer Level	Elapsed Time	Resultant Object File Size
  0	10 seconds	702 blocks
  1	14 seconds	702 blocks
  2	18 seconds	702 blocks
  3	18 seconds	731 blocks
  4	18 seconds	770 blocks

• The following results came from a compile of a 40,000 line monster program (which should be broken up) with 20 external functions and many system calls.

  Optimizer Level	Elapsed Time	Resultant Object File Size
  0	11 minutes	13,558
  1	19 minutes	13,562
  2	42 minutes	13,562
  3	42 minutes	13,148
  4	42 minutes	14,616

  BTW, the following system changes were made in order to allow the "monster" program to compile in a reasonable amount of time:

  AUTHORIZE/my account	WSQUO	20,000
  AUTHORIZE/my account	WSEXT	200,000
  AUTHORIZE/my account	PGFLQUO	2,000,000
  SYSGEN	WSMAX	100,000

• The DEC BASIC for OpenVMS Systems "User's Manual" contains the following descriptions for optimizer settings

Optimizer Level	Meaning
0	no optimizations are performed
1	some optimizations (like instruction scheduling) and unused code removal
2	more optimizations (like loop unrolling and split lifetime analysis)
3	more optimizations
4	maximum optimizations

Alpha Family Tree (from news releases, leaks, gossip, and projections)

Notes:

1. Instruction Issue Rate: Integer only vs. (Integer + Float)
2. OOE = Out of Order Execution
3. OCL2 = On Chip Level 2 Cache
4. OCMC = On Chip Memory Controller
5. SMP = Symmetric Multi Processing
6. SMT = Simultaneous Multi Threaded (chip level)
7. "A" and "B" series parts are usually just a "die shrink" with the exception of EV56 which also had an "instruction set" extension
8. 21066, 21066A, and 21164PC (PCA56) are not shown
9. EV6 and EV7 have the same CPU core
10. Cancelled on June 25, 2001 when Compaq announced that they had been seduced by the dark side (Intel's IA-64)

Alpha 'Chip Head' Links

• https://en.wikipedia.org/wiki/DEC_Alpha
• https://en.wikipedia.org/wiki/Alphaserver
• http://www.alasir.com/articles/alpha_history
• Real World Technology's Silicon Insider
  • A Tale of Two Chips Alpha vs. Itanium. This chart compares "McKinley to EV7" and "Madison to EV8"
  • Compaq Sacrifices Alpha and why they did it
  • The Battle in 64-bit land (revisited)
  • Alpha EV8 (part 1) includes a chart with 21064/EV4, 21164/EV5, 21264/EV6, 21364/EV7, 21464/EV8
  • Alpha EV8 (part 2)
  • Alpha EV8 (part 3)
  • The Battle in 64-bit land
• XBITLABS: The History of Alpha Processors: Facts and Comments (includes chipset info)
• Alpha: The History in Facts and Comments (mirror)
• HP Alpha Systems - Documentation Hardware Manuals (EV4, EV6, EV67, EV68)
• The Alpha Architecture Handbook @ www.alphalinux.org
• Alpha: The History in Facts and Comments
• Click RISCy C/C++ Code to read a DECUS article discussing problems that might arise when writing C / C++ programs for RISC architectures
• Digital Technical Journal (DTJ) has been reincarnated as Compaq Technical Journal (CTJ)
  
  • http://www.hpl.hp.com/techreports/Compaq-DEC/
• The Complete Digital Technical Journals
  • http://www.dtjcd.vmsresource.org.uk/

VAX vs Alpha

Performance Comparisons

The following performance documents use an internal metric called PERF which appears to be "CPU oriented". Previously, Digital used a "CPU plus I/O" metric called VUP (VAX Units of Performance) where a VAX-11/780 had a VUP rating of ONE. In the following charts a VAX-11/780 has a PERF rating of EIGHT.

• http://h18002.www1.hp.com/alphaserver/performance/ Alpha Systems Performance
• http://h18002.www1.hp.com/alphaserver/performance/perf_tps.html AlphaServer, VAX, and MIPS performance comparison

Sometime in 2001 we'll be moving our "trouble ticket management" application from our VAX-6430 to an AlphaServer 4100 5/300. Documents behind the links above say the VAX-6430 has a PERF rating of 125 while the AlphaServer 4100 5/300 has a PERF rating of 690. While it is true that my Alpha 4100 boots up 5 times faster than my VAX-6430, only live load tests will prove if it's 5.5 times faster in the real world. (but newer technology is usually better, right?)

p.s. Since I first viewed Compaq's performance comparisons in the Spring of 2000, they've renamed "Alpha PERF" to "Tru64 TPS" but the unit values in the chart have stayed the same. Since Tru64 never ran on VAX (or MIPS), a direct comparison between the hardware platforms is even more unclear.

Relative VAX-Alpha Comparisons using SPEC (Standard Performance Evaluation Corporation)

• click www.spec.org for more information about SPEC benchmarks

CISC vs. RISC

CISC (Complicated Instruction Set Computing) was developed when memory (RAM) was very expensive. Simply described, an instruction was fetched from memory and pulled into the CPU where is was decoded into a sequence of microinstructions (also called microcode). Depending on the instruction (POLY was the worst) or the addressing mode the CPU could be working on a particular operation for much longer than just a few ticks of the clock. The system could potentially start an instruction then need to abort it in order to service an exception (interrupt) then need to restart the aborted instruction thus wasting valuable CPU resources.

RISC (Reduced Instruction Set Computing) was developed as an alternative to CISC when the cost of RAM started to fall rapidly. RISC machines were required to execute each instruction in only one clock cycle (on average) without the necessity of converting to microcode. This meant that complicated addressing modes as well as complicated instructions had to be replaced by simple ones. Some work previously done by one instruction was now done by many which means that a RISC machine in a certain sense is really running microcode out of RAM. Now when exception occurs it is like interrupting a CISC machine between the micro ops.

With microcode out of the way, CPU operation became much more deterministic. This allowed other interesting performance features to be more easily implemented like OOE (Out of Order Execution) and SE (Speculative Execution) along with its cousin Branch Prediction. I won't go into instruction pipelining here except to say that one consequence of it occasionally allows multiple instructions to execute simultaneously.

Example CISC Addressing Modes (I've lost my VAX programming card so here are some PDP examples until I find it) 

 

Note: twelve PDP instructions (including MUL + DIV) supported double operands so the microcode was expected to support every permutation of the addressing modes listed in the above two tables.

Porting Diary #2 (2001-05 to 2001-06)

• Our "skunk works in Waterloo" has just (2001-04-xx) two more AlphaServer 4100 machines from a cancelled project and we've been commissioned to port a relatively large business application (consisting of ~ 350 VMS programs) from a VAX-6430 cluster to Alpha.
  
• Since the second machine will be used as a combination "hot standby" and "development platform", we moved the CPU and memory from the third machine to the first (using the old VAX terminology, the first machine would now be an AlphaServer-4100). An SMP license is required for each additional CPU, and is a little cheaper than a VMS base license.
  
• We ordered the production TCPware license from Process Software (many of our VAX/VMS programs directly call their "FTP Library" and/or "TELNET Library", which means we can't use Compaq's "TCPIP Services 5.1 for OpenVMS")
  
• We ordered the production licenses from Compaq (we already owned some development licenses and used them to get us going while the paper work ran its course)
  
• We started to port the VAX-BASIC code in a way almost identical to Diary #1. The only thing different is that DEC-BASIC 1.3 is now Compaq-BASIC 1.4 for Alpha.
  
• Our VAX-6430 has some services (like a real-timer pager) running from a DMB-32 eight port async mux. Since a similar mux didn't exist on any of the Alphas, we had to acquire a DS-90TL+ terminal server and then moved the async based apps to it, prior to cutover. This was much easier than it sounds.
  
• The production licenses arrived and installed without a hitch (thanks to Stephen Dow of Compaq Canada). Since the BACKUP, RESTORE, and RECOMPILE scripts were all written and tested twice, we attempted a permanent transfer the following Sunday.
  
• I transferred (and merged) SYSUAF.DAT and RIGHTSLIST.DAT but forgot to transfer VMSMAIL_PROFILE.DATA (which meant that mail messages sent to VMS accounts were not forwarded to our corporate mail server). Oops!
  
• The new machine is so fast that my clients thought the system was buggy when they first logged in. The reason for this was the "node identification page" (from sys$announce) would usually be visible on the VAX while syslogin.com checked the terminal type. Now all that stuff fly's by so fast that we'll either delete it, or add WAIT statements to syslogin.com to slow it down :-)
  
• Since we're on a very tight budget, we were forced to purchase a "concurrent use" DEC-BASIC compiler license (the price is about 1/3 of a "full use" license). This means that ongoing development by 3 programmers may be delayed by lack of license resources, so I decided to start a "long needed" source code renovation to reduce compiler time. See the next section for details.

Renovation (not required, but desired)

Many of our 200 programs were written using the following form (which means that we re-compile included functions every time we compile the main program):

1000	%title "my_program.bas"
	%ident "version 1.23"
	option type=explicit
	external long function funct1(long, long)
	external long function funct2(long, long, long)
  	%include "[.fil]file_map1.rec"	! file definitions are in [.fil]
	!
	print funct1(1%,2%)		!
	%include "[.inc]in_line1.inc"	! in line BASIC code is in [.inc]
	print funct2(1%,2%,3%)		!
30000	end				!
	!
30010	%include "[.fun]funct1.fun"	! BASIC functions are in [.fun]
	!
30020	%include "[.fun]funct2.fun"	! BASIC functions are in [.fun]

So I've written a DCL script to compile all of the BASIC functions in [.fun], then used $LIBRARY/CREATE and $LIBRARY/INSERT to store all the object files in a library. Next, we delete all of the included code that comes after "END" then we compile and link like so:

$bas/optim=level=1	my_program.bas
$link			my_program,					-
			current_dir:my_library/library/selective

Odds 'n Ends (other stuff you shouldn't forget)

Subscripts:
1. Make sure you run the standalone program "swxcrmgr" from either ARC or AlphaBIOS and then use the Tools menu to produce a configuration backup to floppy. One time I powered down the machine to move it 3 meters and, for some reason, the machine came up with both MYLEX DAC960 cards having no configuration.

2. we had a collection of async interface scripts (DCL) which were being used by non-technical people. Our original scripts called a VAX version of kermit-32 which was passed a pre-selected port via logical name "ker$comm". The newer version of kermit (called c-kermit) no longer supports this logical. Instead, you must start the program as a DCL Foreign Command and then pass the desired port on the command line like so:

...snip

$ def/user/NOlog sys$input tt
$ if f$getsyi("arch_name") .eqs. "VAX"
$ then
$     def/user/NOlog KER$COMM 'dev_name'
$     run csmis$exe:vms_kermit_33117.exe    ! kermit-32
$ else
$     ckermit == "$csmis$exe:CKV196-AXP-VMS72-NONET.EXE"
$     ckermit -l 'dev_name'
$ endif 

Simple Metrics

Tape Storage

Our used AlphaServer 4100s were delivered without any built-in tape storage devices and we need to have daily backups of our database. I located a neat "4 mm DAT" ( DS-TLZ10-VA ) which plugs into one slot of our StorageWorks box (Apparently, any device ending in "-VA" can plug into a StorageWorks box) . I ordered one, then installed it while the system was running using the following command:

$ mcr sysman
SYSMAN> io autoconfig
SYSMAN> exit
$

Very fast...

Executive Summary (Port 2)

• port of ~400  VAX-BASIC apps (with system calls sys$crmpsc and sys$mgblsc) previously running under VMS 6.2
• total work time was one person working 8 weeks in my spare time
• time included source code renovation to cleanup problems created by junior programmers (the old stuff worked but one wonders how? I'm glad we caught this stuff before it bit us on the butt)

Decommissioning VAX (2001-09-05)

After we cutover our application to the AlphaServer-4100, we left our two VAXs (one production VAX-6430 and one DRP VAX-6410) powered up and connected to the corporate network incase we neglected to copy something or needed to cut back for some reason. Well, the cutover was four weeks ago and now it was time to decommission the VAX's.

As the machines were rolled out of our computer room, I decided to remove the gray plastic "Digital" name plate from the front door as well as the very cool digital-branded chrome-plated door key as keep sakes (they now sit on my desk; I intended to hang the plastic logo on my key chain but can't bear to drill the hole). I had installed these machines when Digital Equipment Corporation was still a company and this is truly the end of an era for me.

p.s. This happened the day after HP and Compaq announced they'll merge into the New-HP. Since HP is considered an engineer's company (I've always thought of HP's Bill Hewlett and David Packard as the same kind of people as Digital's Ken Olsen and Gordon Bell), let's hope that the Digital Equipment division of Compaq has found a better home.

You Can't Afford to Delay a VAX-to-Alpha Port

1. Spare Parts Availability (for VAX)
   Compaq ended VAX hardware manufacturing in December 2000. Since VAX was the Chevy of minicomputers, spare parts on the street will be available for quite some time but I wouldn't want to go shopping during an emergency.
    
2. Environmental Costs
   Alpha platforms are much smaller and thus save valuable real estate. They also require much less power and, as a result, generate much less heat which means that air conditioning costs will be lower. (many companies don't even bother with an environmentally controlled computer room)
    
3. Platform Costs
   Compared to departmental class VAX machines 10 years ago, departmental class Alphas appear to be 10 times faster but are 10 times cheaper. Compaq allowed us to trade-in our software licenses which made the whole changeover more palatable to the bean counters.
    
4. Better Software Tools
   I've noticed a philosophical change in the way Alpha tools produce code. Check out the following program stub:
   

   1000	option type=explicit	!
   	declare long i%		!
   	for i% = 1 to 100	! should be "for i% = 1% to 100%" on VAX; Alpha doesn't care
   		print i%	!
   	next i%			!
   	end program 1		! return -s- to DCL

   
   Notice that the programmer forgot to place percent symbols after numeric constants "1" and "100"

   Compaq-BASIC for VAX (a.k.a. VAX-BASIC) will generate floats for these numbers then will convert them to longs at "run time" before using them.
   
   Compaq-BASIC for Alpha is smart enough to realize that longs are required and so builds longs at "compile time".
   
   I've personally wasted many months of my life make sure that percent symbols are located everywhere they're supposed to be along with a lot of other stuff. Since software is supposed to assist us, features like these are a welcome relief.
   
   So-called "DEC languages" targeted at Alpha and Itanium are based upon the GEM Optimizing Compiler System. GEM is a project code-name rather than an acronym. Everything coming out of DEC in those days had names like GEM, Emerald, Opal, Prism, Mica, etc.
   
   A Few GEM links:

   1. http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art8.pdf
   2. http://www.dtjcd.vmsresource.org.uk/pdfs/dtj_v04-04_1992.pdf
   3. http://h41379.www4.hpe.com/openvms/journal/v5/portingmacrocompiler.html

Finally, a "NEW" Alpha Server DS20e (2002-01-19)

Management has determined that we've earned our wings with the used Alphas and has decided to replace our primary "Alpha Server 4100" with a brand new "Alpha Server DS20e". BTW, there was no performance reason to change; the AS-4100 will become our DRP (hot standby) machine located in another building.

The new machine is a rocket but I can't post any stats yet because we haven't yet cut over our application software and customer data. But check out the basic differences in the following chart.

Superscript Notes:

1. We purchased this option. Alphas in our computer room are connected via DECnet Phase IV running over FDDI (fiber optic lines) to allow a second backup/restore method if we ever loose our tape drive.
2. We didn't require a VGA terminal on the DS20E (since the RA-3000 is configured via a serial port using PC based software rather than host based software). Yippee! We're back to a VT-510 and can edit startup files in SYS$MANAGER from the console.
3. Want to make your system really fly? Change the "caching policy" of your HSZ22 to "write-back" ("unchecked" defaults to write-through). One of our "I/O bound" database scan-and-analyze programs required a full 2-minutes to run. Changing the caching policy to "write back" caused the execution time to drop to 20 seconds. But make sure your RAID is connected to a UPS or you might not be able to do the write-back (which will result in "data loss")

(a welcome) Licensing Surprise

All the AS-4100 licenses appear to run as-is on the AS-DS20e. This would not have happened in the VAX days and is probably one good reason (out of many) to buy new Alpha hardware.

Tiny Little Problem (resolved)

Our DS20e was delivered with a modern two port 10/100 Ethernet card. However, my employer required me to connect it to a 10 year old Synoptics Hub which only supports 10 Mb/s. Whenever we would disconnect the 10-base-T connector (a very rare event), the DS20e Ethernet port wouldn't recover after reconnection. The next time down, we used console mode to permanently change the port settings from "AUTO" to "10 Mb/s Full Duplex".

Note that this change on our part was a mistake since "full duplex" is only meant for Ethernet switches but not hubs (it made TCP/IP appear slow while DECnet phase IV was intermittent). We shut down the system ASAP and changed the console setting of the Ethernet ports to just "10 Mb/s" (half duplex is assumed) which returned the system to its ridiculously fast speed.

>>> set eia0_mode twisted

AlphaServer DS20 Console Manuals:

• ds20_guide.pdf
• ds10cr-d.pdf

2008-06-17 Update: Our company runs two networks so...

1. our primary NIC connected to the legacy network (based upon Synoptics hubs) running 10 Mbs half-duplex
2. our secondary NIC is connected to the newer switched networked (based upon CISCO Ethernet Switches). The second NIC is set to auto-negotiate like so:

   >>> set eia1_mode auto-negotiate

   and is currently running 100 Mb/s full-duplex

AlphaServer DS20e Memory Upgrade (2005-09-xx)

When we purchased our DS20e from Compaq (now HP) back in 2002-01-xx it came with only 1 GB of RAM. Recently a third party vendor (SystemResale.com) offered to sell me an additional 1 GB kit at a very attractive price under $1K. Since we do our own maintenance, and because the price was so low, I decided to do the upgrade myself.

Well you wouldn't believe what happened next. This system became so fast that it was actually scary. It seems that OpenVMS-7.3-2 had cached quite a bit of our RMS database (as well as a lot of other files) in memory which resulted in almost no physical I/Os to disk but an enormous amount of lock activity (which I interpreted as a large amount of work being compressed into a smaller period of time). We immediately went back to our third party vendor and ordered another 1 GB kit which brought up our total memory to 3 GB.

I do not have any before/after measurements to offer but my DS20e feels like it is now 10 times more powerful now than before the memory upgrade.

More Speed Comes to the AlphaServer DS20e (2007)

Installed two more memory kits (we now host 4 GB) then allocated 2 GB to the XFC (extended file cache)

More Speed Comes to the AlphaServer DS20e (2009)

Switched the caching policy of our RA-3000 (raid controller) from write-through to write-back. System performance is now "scary fast"

The Saga Continues (2015)

• "Alpha to Itanium" Porting Diary
  Caveat: HP is still confusing the marketplace by calling this "Intel processor technology" HP Integrity which is probably why Itanium is less well known in popular culture and HP Integrity even less so.

---

 Back to Home
Neil Rieck
Waterloo, Ontario, Canada.