OpenVMS Notes: "VAX to Alpha" Porting Diaries

Porting Diary #1 (1999-11-xx to 2000-01-xx)

Week 1 (My first Alpha...)

Our "skunk works" has just (1999-11-30) received an AlphaServer 4100s (with DUNIX 4.1 installed) from a cancelled project and we've been commissioned to port a relatively large app from a dual VAX-8550 cluster to Alpha.

This specific machine is an AlphaServer 4100 5/300 which was manufactured in 1996. It contains 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 an " 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.

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" RMS file 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 VAX to the 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 (Windows95/98/NT 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 and start up both 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/HP'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 bit different from VAX-BASIC

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

note: DEC-BASIC has been renamed Compaq-BASIC (and then HP-BASIC)

• 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, I can only imagine what the compiler now has to do when generating instructions for a pipelined super scalar 64 bit RISC CPU

• 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 the 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"

• 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?

Program Renovation: Our currently semi-formal method of declaring external functions has made me question whether porting programs to a new hardware architecture will always be safe. Everything has worked properly so far but I keep thinking that 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.
• 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 actually work at run time, but it will overwrite a neighboring variable causing unpredictable results.

	1000	! informal example (we never do this)
		option type=explicit
		record QuadWord
			long long0
			long long1
		end record
		external long function sys$bintim	! informal
		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 "data type" or "passing mechanism" errors. The problem here is that every external function and constant needs to be declared. 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.

	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 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 BASIC library is incorrect while the manual "OpenVMS RTL Library (LIB$) Manual" is correct. 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
	  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 people at Compaq and was told it was probably a documentation error associated with OpenVMS-7.2-1 (follow up note: this was finally fixed with the documentation associated with OpenVMS-7.3-1)
  
  In library BASIC$STARLET the second argument of these affected LIB$ROUTINE calls are declared to be an address PASSED BY VALUE rather than a variable PASSED BY REFERENCE (e.g. address), the fix requires us to use BASIC's LOC() function to determine the address and then let the compiler use the "library declared" passing mechanism as follows:

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.
• If the following example is compiled with optimize level 1 or higher, no run time error occurs because the compiler "knows" that the variables aren't used so the generating lines are discarded.

  1000	option type=explicit
  	declare long a,b,c
  	a = 4 + 5	! optimizer removes this second
  	b = a / 0	! optimizer removes this first
  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.

$ type pos_spnnnnnnn.bas
1000    option type=explicit
	map(abc) string dev_name$ = 8			! fixed length string
	dev_name$ = "LTA9999"
	if pos(dev_name$,":",1%)>0% then
	    dev_name$ = dev_name$ +":"			! the problem line
!~~~	    dev_name$ = edit$(dev_name$,128%) +":"	x the fixed line
	end if
	print dev_name$
30000	end
$ bas/optim=level=0/warn=all pos_demo

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
$ bas/optim=level=1/warn=all pos_demo
$							! 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.

$ type logic_demo.bas
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
	    print "error: ";rc%
	end if
30000	end
$ bas/optim=level=0/warn=all logic_demo <-- produces no messages
$ bas/optim=level=1/warn=all logic_demo

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 work time was one person working <8 weeks in my spare time

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 cheap. 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

• Some people think that the Alpha will be eclipsed by Intel's IA-64 (a.k.a. Itanium; Itanic; Un-obtanium) when it appears on the market in the spring of 2002. This may not happen for a number of reasons which include the following:

• Intel drove away many industrial customers when it brought out its patented "SLOT 1" and "SLOT 2" interface technology accompanied by sky-high royalty fees
  Note: "SLOT 1" is for non-Celeron Pentium-II (and up) while "SLOT 2" is for Xeon class Pentiums used in servers.
• Compaq countered by bringing out patented "SLOT A" and "SLOT B" technology accompanied by very low royalty fees. (check out AMD's Athlon product)
• Compaq needed to drop the cost of Alpha chips as well as get a foot hold on the Pacific rim so they signed deals with both Samsung Semiconductor and Mitsubishi to produce second source components
• Compaq and Samsung joined together to form an alliance which will produce Alpha systems and motherboards. The name of this company is API (Alpha Processor Inc.) and their web address is www.alpha-processor.com I should point out that API only deals in Linux and Tru64 solutions, not OpenVMS.
  Oops! API went of of business in 2002-04 after Compaq sold the Alpha design to Intel and Samsung ended their funding of API
• Compaq recently asked IBM to produce a copper Alpha to get the clock speed over 1 GHz and IBM succeeded (is this IBM's revenge on the Wintel alliance?)
• Alpha technology has been on the scene since 1992 which means it's had a 10 year jump on Itanium. If Compaq keeps the price down and continues to advance the technology, Itanium may become a foot note in history just like the Intel iAPX-432 which was cancelled in 1983.

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 h71000.www7.hp.com/freeware/freeware40/macro64/ 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:
01. Instruction Issue Rate: Integer only vs. (Integer + Float)
02. OOE = Out of Order Execution
03. OCL2 = On Chip Level 2 Cache
04. OCMC = On Chip Memory Controller
05. SMP = Symmetric Multi Processing
06. SMT = Simultaneous Multi Threaded (chip level)
07. "A" and "B" series parts are usually just a "die shrink" with the exception of EV56 which also had an "instruction set" extension
08. 21066, 21066A, and 21164PC (PCA56) are not shown
09. 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

• http://en.wikipedia.org/wiki/DEC_Alpha
• http://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
• Advanced info for 21464 (EV8) and 21364 (EV7)
  • Microprocessor Forum: Designers cut fresh paths to parallelism
  • Simultaneous Multi Threading Project at the University of Washington (many articles in PDF format) including:
    • Simultaneous Multithreading: Multiplying Alpha Performance (in PPT format)
• XBITLABS: The History of Alpha Processors: Facts and Comments (includes chipset info)
• Alpha: The History in Facts and Comments (mirror)
• 21264 overview and 21264 product brief (includes EV6, EV67 and EV68)
• 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
• Compaq free Math libraries including CPML (Compaq Portable Math Library) and CXML (Compaq Extended Math Library)
• http://ftp.digital.com/pub/Digital/Alpha/firmware/index.html Alpha Console Firmware documentation
• Recently rediscovered old issues of Digital Technical Journal (DTJ):
  (this is only a partial list)

  Digital Technical Journal - Index
  Digital Technical Journal Volume 4, Number 4, Special Issue 1992	- describes the 21064 (EV4)
  Digital Technical Journal Volume 6, Number 1, Winter 1994	- evolution of  21066 (AXP PC)
  Digital Technical Journal Volume 6, Number 2, Spring 1994	- evaluation kit for the 21064
  Digital Technical Journal Volume 7, Number 1, Special Edition 1995	- describes the 21164 (EV5) - AlphaServer 2100 systems
  Digital Technical Journal Volume 8, Number 4	- describes the AlphaServer 4100 - Instruction Execution on Alpha Processors
  http://www.hpl.hp.com/hpjournal/dtj/	- raw list of documents

• Digital Semiconductor Literature FTP area including 21264 (EV6) :
  • archives index 26k
  • doc index 20k
• Digital Technical Journal (DTJ) has been reincarnated as Compaq Technical Journal (CTJ)
  (note that this is only a partial list)

  http://www.hpl.hp.com/techreports/Compaq-DEC/

  - list of Compaq Publications

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 Alpha Server 4100 5/300. Documents behind the links above say the VAX-6430 has a PERF rating of 125 while the Alpha Server-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-xx to 2001-06-xx)

• Our skunk works has just (2001-04) received three AlphaServer 4100s (with DUNIX 4.1 installed) from a cancelled project within our company and we've been commissioned to port a relatively large app from a VAX-6430 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 complier 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)

Superscript Notes:

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 the logical "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

Machine	Memory	CPUs	OS	Boot Time	Storage	Avg Disk I/Os ($mon disk)	Max Disk I/Os ($mon disk)
VAX-6430 manufactured: 1989	256M	3	OpenVMS-7.2	11.5 min	2 DSSI busses 2 StorageWorks boxes 2 HSD05 adapters 8 RZ26 drives 4 shadow sets (across 2 busses)	23	32
AlphaServer-4100 (EV5@300MHz)1 manufactured: 1996	512M	2	OpenVMS-7.2-1	< 2 min	2 Mylex DAC960 24 RZ29 drives 4 RAID-5 sets 1 SCSI adapter 1 StorageWorks box 2 RZ29 drives	312	610

Superscript Notes:
1. a new AlphaServer with EV68 (or 69) technology would make this Alpha look like a VAX (and the VAX look like a PDP)

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. Using this link I found 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 cool (and 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 (with temporary addresses) 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 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. Who knows; maybe Carly Fiorina will revive the Alpha Microprocessor Division.

You Can't Afford to Delay an 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 will be available for quite some time, but I wouldn't want to go shopping during an emergency.
   Link: The End of VAX Hardware Production
    
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://source.rfc822.org/pub/mirror/ftp3.ds.pg.gda.pl/people/macro/DEC/DTJ/DTJ808/DTJ808PF.PDF
   3. http://h71000.www7.hp.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 a 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 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" aka write-through is the default). 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

Tiny Little Problem (resolved)

>>> 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

DS20e Memory Upgrade (2005-09-xx)

Other Links:

1. OpenVMS Services at www.migrationspecialties.com
2. CETS2001 - The Third Porting: Applying Past Lessons to the Alpha/Itanium Transition
3. http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00481276/c00481276.pdf (RA-3000 hardware)
4. http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00481219/c00481219.pdf (Command Console V2.2)
5. http://www.compaq.com/legacysupport/digital/pdf/clusuia.pdf BA356 Installation Guide
6. Dave Cutler, PRISM, Mica, Emerald, etc.

Click for the latest reality check from our hero

Join the OpenVMS WebRing Previous  SkipPrevious  SkipNext  Next List  Random  Next5

Back to OpenVMS
 Back to Home
 Neil Rieck
 Kitchener - Waterloo - Cambridge, Ontario, Canada.