The ModulaTor logo 7KB

The ModulaTor

Oberon-2 and Modula-2 Technical Publication

Erlangen's First Independent Modula_2 Journal! Nr. 3/Apr-1992


Mythen in Tüten

Computer Virus Myths


(8th Edition, March 1992)

by Rob Rosenberger with Ross M. Greenberg

A number of myths have surfaced about the threat of computer viruses. There are myths about how widespread they are, how dangerous they are, and even myths about what a computer virus really is. We'd like the facts to be known.

The first thing to learn is that a virus is a malicious programming technique in the realm of Trojan horses. All viruses are Trojan horses, but few Trojan horses can be called a virus.

That having been said, it's time to go over the terminology we use when we lecture:

BBS Bulletin Board System. If you have a modem, you can call a BBS and leave messages, transfer computer files back & forth, and learn a lot about computers. (What you're reading right now, for example, most likely came to you from a BBS.)

Bug an accidental flaw in the logic of a program which makes it do things it shouldn't really be doing. Programmers don't mean to put bugs in their program, but they always creep in. Programmers tend to spend more time debugging their programs than they do writing them in the first place. Inadvertent bugs have caused more data loss than all the viruses combined.

Hacker someone who really loves computers and who wants to push them to the limit. Hackers have a healthy sense of curiosity: they try doorknobs just to see if they're locked, and they tinker with a piece of equipment until it's just right. The computer revolution itself is a result of hackers.

Shareware a distribution method for quality software available on a try before you buy basis. You pay for the program only if you find it useful. Shareware programs can be down- loaded from BBSs and you are encouraged to give evaluation copies to friends. Many shareware applications rival the power of off-the-shelf counterparts, at just a fraction of the price. (You must pay for the shareware you continue to use -- otherwise you're stealing software.)

Trojan horse a generic term describing a set of computer instructions purposely hidden inside a program. Trojan horses tell a program to do things you don't expect it to do. The term comes from a legendary battle in which the ancient city of Troy received the gift of a large wooden horse. The gift secretly held soldiers in its belly, and when the Trojans rolled it into their fortified city....

Virus a term for a very specialized Trojan horse which spreads to other computers by secretly infecting programs with a copy of itself. A virus is the only type of Trojan horse which is contagious, like the common cold. If it doesn't meet this definition, then it isn't a virus.

Worm a term similar to a Trojan horse, but there is no gift involved. If the Trojans had left that wooden horse outside the city, they wouldn't have been attacked. Worms, on the other hand, can bypass your defenses without having to deceive you into dropping your guard. An example is a program designed to spread itself by exploiting bugs in a network software package. Worms are usually released by someone who has normal access to a computer or network.

Wormers the name given to the people who unleash destructive Trojan horses. Let's face it, these people aren't angels. What they do hurts us. They deserve our disrespect.

Viruses, like all Trojan horses, purposely make a program do things you don't expect it to do. Some viruses are just an annoyance, perhaps only displaying a Peace on earth greeting. The viruses we're worried about are designed to destroy your data (the most valuable asset of your computer!) and waste your valuable time in recovering from an attack.

Now you know the difference between a virus and a Trojan horse and a bug. Let's get into some of the myths:

All purposely destructive code comes as a virus.

Wrong. Remember, Trojan horse is the general term for purposely destructive code. Very few Trojan horses actually qualify as viruses. Few newspaper or magazine reporters have a real understand of computer crimes, so they tend to call almost anything a virus.

Viruses and Trojan horses are a recent phenomenon.

Trojan horses have been around since the first days of the computer; hackers toyed with viruses in the early 1960s as a form of amusement. Many different Trojan horse techniques emerged over the years to embezzle money, destroy data, etc. The general public didn't know of this problem until the IBM PC revolution brought it into the spotlight. Banks still hush up computerized embezzlements (as they did during the 1980s) because they believe customers will lose faith in their computer systems if the word gets out.

Viruses are written by hackers.

Yes, hackers have purposely unleashed viruses, but so has a computer magazine publisher. And according to one trusted military publication, the U.S. Defense Department develops them as weapons. Middle-aged men wearing business suits created Trojan horses for decades before the advent of computer viruses. We call people wormers when they abuse their knowledge of computers. You shouldn't fear hackers just because they know how to write viruses. This is an ethics issue, not a technology issue. Hackers know a lot about computers; wormers abuse their knowledge. Hackers (as a whole) got a bum rap when the mass media corrupted the term.

Viruses infect 25% of all IBM PCs every month.

If 25% suffer an infection every month, then 100% would have a virus every four months assuming the user took no preventive measures -- in other words, every IBM PC would suffer an infection three times per year. This astronomical estimate surfaced after virus expert (and antivirus vendor) Dr. Peter Tippett published The Kinetics of Computer Virus Replication, a complex thesis on how viruses might spread in the future. Computer viruses exist all over the planet, yes -- but they won't take over the world. Only about 400 different viruses exist at this time and some of them have been completely eliminated from the wild. (Of course, virus experts retain copies even of extinct viruses in their archives.) You can easily reduce your exposure to viruses with a few simple precautions. Yes, it's still safe to turn on your computer!

Only 400 different viruses? But most experts talk about them in the thou- sands.

The virus experts who originate these numbers tend tto work for antivirus firms. They count even the most insignificant variations of viruses as part of the grand total for advertising purposes. When the Marijuana virus first appeared, for example, it displayed the word legalise, but a miscreant later modified it to read legalize. Any program capable of detecting the original virus will detect the version with one letter changed -- but antivirus companies count them as two viruses. Such obscure differentiations quickly add up.

Viruses could destroy all the files on my disks.

Yes, and a spilled cup of coffee will do the same thing. If you have adequate backup copies of your data, you can recover from any virus or coffee problem. Backups mean the difference between a nuisance and a disaster. It is safe to presume there has been more accidental loss of data than loss by viruses and Trojan horses.

Viruses have been documented on over 300,000 computers (1988).

Viruses have been documented on over 400,000 computers (1989).

Viruses have been estimated on over 5,000,000 computers (1992).

These numbers come from John McAfee, a self-styled virus fighter who craves attention and media recognition. If we assume it took him a mere five minutes to adequately document each viral infection, it would have taken four man-years of effort to document a problem only two years old by 1989. We further assume McAfee's statements include every floppy disk ever infected up to that time by a virus, as well as all of the computers participating in the Christmas and InterNet worm attacks. (Worms cannot be included in virus infection statistics.)

McAfee prefers to estimate his totals these days. Let's assume we have about 100 million computers of all types & models in use around the world. McAfee's estimate means 1 out of every 20 computers on the planet supposedly has a virus. It sounds like a pretty astronomical number to most other virus experts.

Viruses can hide inside a data file.

Data files can't wreak havoc on your computer -- only an executable program file can do that (including the one that runs when you first turn on your computer). If a virus infected a data file, it would be a wasted effort. But let's be realistic: what you think is 'data' may actually be an executable program file. For example, a batch file qualifies as text on an IBM PC, yet the MS-DOS operating system treats it just like a program.

BBSs and shareware programs spread viruses.

Here's another scary myth drummed up in the big virus panic, this one spouted as gospel by many experts who claim to know how viruses spread. The truth, says PC Magazine publisher Bill Machrone, is that all major viruses to date were transmitted by [retail] packages and private mail systems, often in universities. (PC Magazine, October 11, 1988.) Machrone said this back in 1988 and it still applies to this day. Almost 50 retail companies so far have admitted spreading infected master disks to tens of thousands of customers since 1988 -- compared to only five shareware authors who have spread viruses on master disks to less than 100 customers. Machrone goes on to say bulletin boards and shareware authors work extraordinarily hard at policing themselves to keep viruses out. Reputable sysops check every file for Trojan horses; nationwide sysop networks help spread the word about dangerous files. Yes, you should beware of the software you get from BBSs and shareware authors, but you should also beware of the retail software you find on store shelves. (By the way, many stores now have software return policies. Do you know for sure you were the only one who used those master disks?)

My computer could be infected if I call an infected BBS.

BBSs can't write information on your disks -- the communications software you use performs this task. You can only transfer a dangerous file to your computer if you let your software do it. And there is no 300bps subcarrier that lets a virus slip through a high speed modem. A joker named Mike RoChenle (IBM's micro channel PS/2 architecture, get it?) started the 300bps myth when he left a techy-joke message on a public BBS. Unfortunately, a few highly respected journalists were taken in by the joke.

So-called 'boot sector' viruses travel primarily in software downloaded from BBSs.

This common myth -- touted as gospel even by Australia's Computer Virus Information Group -- expounds on the mythical role computer bulletin boards play in spreading viruses. Boot sector viruses can only spread by direct contact and booting the computer from an infected disk. BBSs deal exclusively in program files and have no need to pass along copies of disk boot sectors. Bulletin board users therefore have a natural immunity to boot- sector viruses when they download software.

We should make a special note about dropper programs developed by virus researchers as an easy way to transfer boot sector viruses among themselves. Since they don't replicate, dropper programs don't qualify as a virus in and of themselves. Such programs have never been discovered on any BBS to date and have no real use other than to transfer infected boot sectors.

My files are damaged, so it must have been a virus attack.

It also could have happened because of a power flux, or static electricity, or a fingerprint on a floppy disk, or a bug in your software, or perhaps a simple error on your part. Power failures and spilled cups of coffee have destroyed more data than all viruses combined.

Donald Burleson was convicted of releasing a virus.

Newspapers all over the country hailed a Texas computer crime trial as a virus trial. The defendent, Donald Burleson, was in a position to release a destructive Trojan horse on his employer's mainframe computer. This particular software couldn't spread to other computers, so it couldn't possibly have qualified as a virus. Davis McCown, the prosecuting attorney, claims he never brought up the word virus during the trial. So why did the media call it one?

1. David Kinney, an expert witness testifying for the defense, claimed Burleson had unleashed a virus. The prosecuting attorney didn't argue the point and we don't blame him -- Kinney's bizarre claim probably helped sway the jury to convict Burleson, and it was the defense's fault for letting him testify.

2. McCown gave reporters the facts behind the case and let them come up with their own definitions. The Associated Press and USA Today, among others, used such vague definitions that any program would have qualified as a virus. If we applied their definitions to the medical world, we could safely label penicillin as a biological virus (which is, of course, absurd).

3. McCown claims many quotes attributed to him were misleading or fabricated and identified one in particular which is total fiction. Reporters sometimes print a quote out of context, and McCown apparently fell victim to it. (It's possible a few bizarre quotes from David Kinney or John McAfee were accidentally attributed to McCown.)

Robert Morris Jr. released a benign virus on a defense network.

It may have been benign but it wasn't a virus. Morris, the son of a chief computer scientist at the U.S. National Security Agency, decided one day to take advantage of a bug in the Defense Department's networking software. This tiny bug let him send a worm through the network. Among other things, Morris's InterNet worm sent copies of itself to other computers in the network. Unfortunately, the network clogged up in a matter of hours due to some bugs in the worm module itself. The press originally called it a virus, like it called the Christmas worm a virus, because it spread to other computers. Yet Morris's programs didn't infect any computers. A few notes:

1. Reporters finally started calling it a worm a year after the fact, but only because lawyers in the case constantly referred to it as a worm.

2. The worm operated only on Sun-3 & Vax computers which employ a UNIX operating system and were specifically linked into the InterNet network at the time.

3. The 6,200 affected computers cannot be counted in virus infection statistics (since they weren't infected).

4. It cost way less than $98 million to clean up the attack. An official Cornell University report claims John McAfee, the man behind this wild estimate, was probably serving [him]self in an effort to drum up business. People familiar with the case estimated the final figure at under $1 million.

5. Yes, Morris could easily have added some infection code to make it a worm/virus if he'd had the urge.

6. The network bug exploited in the attack has since been fixed.

7. Morris went to trial for launching the InterNet worm and received a federal conviction. The Supreme Court refused to hear the case, so his conviction stands.

The U.S. government planted a virus in Iraq military computers during the Gulf War.

U.S. News & World Report published a story in early 1992 accusing the National Security Agency of replacing a computer chip in a printer bound for Iraq just before the Gulf War with a secret computer chip containing a virus. The magazine cited two unidentified senior U.S. officials as their source, saying once the virus was in the [Iraqi computer] system, ...each time an Iraqi technician opened a 'window' on his computer screen to access information, the contents of the screen simply vanished. However, the USN&WR story shows amazing similarities to a 1991 April Fool's story published by InfoWorld magazine. Most computer experts dismiss the USN&WR story as a hoax -- an urban legend innocently created by the Info- World joke. Some notes:

1. USN&WR has refused to retract the story, but it did issue a clarification stating it could not be confirmed that the [virus] was ultimately successful. The editors broke with tradition and refused to publish any of the numerous letters readers submitted about the virus story.

2. Ted Koppel, a well-known American news anchor, opened one of his Nightline broadcasts with a report on the alleged virus. Koppel's staff politely refers people to talk with USN&WR about the story's validity.

3. InfoWorld didn't label their story as fiction, but the last paragraph identified it as an April Fool's joke.

Viruses can spread to all sorts of computers.

All Trojan horses are limited to a family of computers, and this is especially true for viruses. A virus designed to spread on IBM PCs cannot infect an IBM 4300 series mainframe, nor can it infect a Commodore C64, nor can it infect an Apple Macintosh.

My backups will be worthless if I back up a virus.

No, they won't. Let's suppose a virus does get backed up with your files. You can restore important documents and databases -- your valuable data -- without restoring an infected program. You just reinstall programs from master disks. It's tedious work, but not as hard as some people claim.

Antivirus software will protect me from viruses.

There is no such thing as a foolproof antivirus program. Trojan horses and viruses can be (and have been) designed to bypass them. Antivirus products themselves can be tricky to use at times, and they occasionally have bugs. Always use a good set of backups as your first line of defense; rely on antivirus software as a second line of defense.

Read-only files are safe from virus infections.

This common myth among IBM PC users has been printed even in some computer magazines. Supposedly, you can protect yourself by using the DOS ATTRIB command to set the read-only attribute on program files. However, ATTRIB is software -- and what it can do, a virus can undo. The ATTRIB command seldom halts the spread of viruses.

Viruses can infect files on write-protected disks.

Here's another common IBM PC myth. If viruses can modify read-only files, people assume they can modify write-protected floppies. However, the disk drive itself knows when a floppy is protected and refuses to write to it. You can physically disable an IBM PC drive's write-protect sensor, but you can't override it with a software command.

We hope this dispels the many computer virus myths. Viruses DO exist, they ARE out there, they WANT to spread to other computers, and they CAN cause you problems. But you can defend yourself with a cool head and a good set of backups.

The following guidelines can shield you from Trojan horses and viruses. They will lower your chances of being infected and raise your chances of recovering from an attack.

1. Implement a procedure to regularly back up your files and follow it religiously. Consider purchasing a user-friendly program to take the drudgery out of this task. (There are plenty to choose from.)

2. Rotate between at least two sets of backups for better security (use set #1, then set #2, then set #1...). The more sets you use, the better protected you are. Many people take a master backup of their entire hard disk, then take incremental backups of those files which changed since the last time they backed up. Incremental backups might only require five minutes of your time each day.

3. Download files only from reputable BBSs where the sysop checks every program for Trojan horses. If you're still afraid, consider getting programs from a BBS or disk vendor company which gets them direct from the authors.

4. Let newly uploaded files mature on a BBS for one or two weeks before you download it (others will put it through its paces).

5. Consider using a program that searches, or scans, disks for known viruses. Almost all infections to date involved viruses known to antivirus companies. A recent copy of any scanning program will in all probability identify a virus before it gets the chance to infect your computer -- and as they say, an ounce of prevention is worth a pound of cure. A scanning program can dramatically lower your chaces of getting infected by a computer virus in the first place. (But remember: there is no perfect antivirus defense.)

6. Consider using a program that creates a unique signature of all the programs on your computer. Run this program once in awhile to see if any of your software applications have been modified -- either by a virus or by a fingerprint on a floppy disk or perhaps even by a stray gamma ray.

7. Don't panic if your computer starts acting weird. It may be a virus, but then again maybe not. Immediately turn off all power to your computer and disconnect it from any local area networks. Reboot from a write-protected copy of your master DOS disk. Do not run any programs on a regular disk (you might activate a Trojan horse). If you don't have adequate backups, try to bring them up to date. Yes, you might back up a virus as well, but it can't hurt you if you don't use your normal programs. Set your backups off to the side. Only then can you safely hunt for problems.

8. If you can't figure out what's wrong and you aren't sure what to do next, turn off your computer and call for help. Consider calling a local computer group before you call for an expert. If you need a professional, consider a regular computer consultant first. Some virus removal experts charge prices far beyond their actual value.

9. [Consider this ONLY as a last resort.] If you can't figure out what's wrong and you are sure of yourself, execute both a low-level and a high-level format on all your regular disks. Next, carefully re- install all software from the master disks (not from the backups). Make sure the master disks have write-protect tabs! Then, carefully restore only the data files (not the program files) from your backup disks.

We'd appreciate it if you would mail us a copy of any Trojan horse or virus you discover. (Be careful you don't damage the data on your disks while trying to do this!) Include as much information as you can and put a label on the disk saying it contains a malicious program. Send it to Ross M. Greenberg, P.O. Box 908, Margaretville, NY 12254. Thank you.

Ross M. Greenberg is the author of both shareware and retail virus detection programs. Rob Rosenberger is the author of various phone productivity applications. (Products are not mentioned by name because this isn't the place for advertisements.) They each write for national computer magazines. These men communicated entirely by modem while writing this treatise.

Copyright 1988,92 by Rob Rosenberger & Ross M. Greenberg

Rosenberger can be reached electronically on CompuServe as [74017,1344], on GEnie as R.ROSENBERGE, on InterNet as 74017.1344@compuserve.com', and on various national BBS linkups. Greenberg can be reached on MCI and BIX as greenber', on UseNet as c-rossgr@microsoft.com', and on CompuServe as [72461,3212].

You may give copies of this treatise to anyone if you pass it along in its entirety. Publications may reprint it at no charge if they give due credit to the authors and send two copies to: Rob Rosenberger, P.O. Box 643, O'Fallon, IL 62269.

Letters to the Editor


Lund, 03-Mar-1992

Guenter,

Thanks for the valuable information. Perhaps I should also tell a bit more.

Our ultimate purpose is education and research in the field of Automatic Control, and Real Time Programming is a part of this. The equipment we use consists of lab computers with 680x0 CPUs on a VME bus and also analog and digital I/O. We have developed a Real Time Kernel, written in Modula-2, and the students write their programs on top of this kernel. The development machines are Sun 3/50 and SparcStation, and we have good facilities for code downloading. So far we have been using a Modula-2 cross compiler running on Sun3 developed by ... [company named erased by the Editor], but they have gone out of business and we need a replacement that also runs on Sparc.

Yours sincerely, Leif

 Leif Andersson
 Dept. of Automatic Control
 Lund Institute of Technology
 P.O. Box 118
 S-221 00 Lund, Sweden
 Email/Internet: leif@Control.LTH.Se
 Phone: +46 46 109742, Fax: +46 46 138118

DEC's Alpha 21064 Processor Technical Details


Article: 4554 of comp.sys.dec
From: jg@crl.dec.com (Jim Gettys)
Newsgroups: comp.arch,comp.sys.dec,comp.unix.ultrix,comp.unix.cray
Subject: Alpha Architecture Technical Summary
Keywords: Alpha microprocessor, Digital, 64 bit
Date: 25 Feb 92 17:17:38 GMT
Sender: news@crl.dec.com (USENET News System)
Organization: DEC Cambridge Research Lab

Dick Sites is in Tokyo for the Alpha rollout today; he asked me to post this architectural summary of Alpha for your interest. [Ed. note: For complete information, get the latest Alpha Architecture Handbook now.

The current Alpha processor chip is called a 21064. I believe samples are available for customer's evaluation now, according to the sales information I've seen.

I don't want to be a salesman on the net here, but to avoid the flood of mail I'd otherwise recieve, I include a phone number for more information.

To learn more about pricing and availability of the 21064 microprocessor in its 150 MHz or faster clock rate versions, contact your local Digital sales representative. Or, in the United States, call 1-800-DEC-2717; 1-800-DEC-2515 (TTY).

Some spec's on the chip follow the Architecture summary below.

- Jim Gettys

ALPHA ARCHITECTURE TECHNICAL SUMMARY Dick Sites, Rich Witek

[NOTE: "Alpha" is an internal code name. An official name will be announced soon.]

WHAT IS ALPHA?

Alpha is a 64-bit RISC architecture, designed with particular emphasis on speed, multiple instruction issue, multiple processors, software migration from VAX VMS and MIPS ULTRIX, and long lifetime. The architects rejected any feature that did not appear to be usable for at least 25 years.

The first chip implementation runs at up to 200 MHz. The speed of Alpha implementations is expected to scale up from this by at least a factor of 1000 over the next 25 years.

FORMATS

Data Formats

Alpha is a load/store RISC architecture with all operations done between registers. Alpha has 32 integer registers and 32 floating registers, each 64 bits. Integer register R31 and floating register F31 are always zero. Longword (32-bit) and quadword (64-bit) integers are supported. Four floating datatypes are supported: VAX F-float, VAX G-float, IEEE single (32-bit), and IEEE double (64-bit). Memory is accessed via 64-bit virtual little-endian byte addresses.

Instruction Formats

Alpha instructions are all 32 bits, in four different instruction formats specifying 0, 1, 2, or 3 register fields. All formats have a 6-bit opcode.



        +-----+-------------------------+
        | OP  |                number                | PALcall
        +-----+----+--------------------+
        | OP  | RA |        disp                | Branch
        +-----+----+----+---------------+
        | OP  | RA | RB |    disp        | Memory
        +-----+----+----+----------+----+
        | OP  | RA | RB |  func.   | RC        | Operate
        +-----+----+----+----------+----+

PALcalls specify one of a few dozen complex operations to be performed.

Conditional branches test register RA and specify a signed 21-bit PC-relative longword target displacement. Subroutine calls put the return address in RA.

Loads and stores move longwords or quadwords between RA and memory, using RB plus a signed 16-bit displacement as the memory address.

Operates use source registers RA and RB, writing result register RC. There is an extended opcode in the 11-bit function field. Integer operates can use the RB field and part of the function field to specify an 8-bit zero-extended literal.

INSTRUCTIONS

PALcall Instructions

The Privileged Architecture Library call instructions specify one of a few dozen complex functions to be performed. These functions deal with interrupts and exceptions, task switching, virtual memory, and other complex operations that must be done atomically. PALcall instructions vector to a privileged library of software subroutines (using the same Alpha instruction set) that implement an operating-system-specific set of these complex operations.

Branch Instructions

Conditional branch instructions can test a register for positive/negative or for zero/nonzero. They can also test integer registers for even/odd. Unconditional branch instructions can write a return address into a register. There is also a calculated jump instruction the branches to an arbitrary 64-bit address in a register.

Load/Store Instructions

Load and store instructions can move either 32- or 64-bit aligned quantities. The VAX floating-point load/store instructions swap words to give a consistent register format for floats. Memory addresses are flat 64-bit virtual addresses, with no segmentation. A 32-bit integer datum is placed in a register in a canonical form that makes 33 copies of the high bit of the datum. A 32-bit floating datum is placed in a register in a canonical form that extends the exponent by 3 bits and extends the fraction with 29 low-order zeros. 32-bit operates preserve these canonical forms.

There are no 8- or 16-bit load/store instructions, but there are facilities for doing byte manipulation in registers.

Alpha has no 32/64 mode bit or other such device. Compilers, as directed by user declarations, can generate any mixture of 32- and 64-bit operations.

Integer Operate Instructions

The integer operate instructions manipulate full 64-bit values, and include the usual assortment of arithmetic, compare, logical, and shift instructions. There are just three 32-bit integer operates: add, subtract, and multiply. These differ from their 64-bit counterparts ONLY in overflow detection and in producing 32-bit canonical results.

There is no integer divide instruction.

In addition to the operations found in conventional RISC architectures, there are scaled add/subtract for quick subscript calculation, 128-bit multiply for division by a constant and multiprecision arithmetic, conditional moves for avoiding branches, and an extensive set of in-register byte manipulation instructions for avoiding single-byte writes.

Rather then keeping a global state bit for integer overflow trap enable, the enable is encoded in the function field of each instruction. Thus, both ADDQ/V and ADDQ opcodes exist for specifying 64-bit add with and without overflow checking. This makes pipelined implementations easier.

Floating-point Operate Instructions

The floating operate instructions include four complete sets of VAX and IEEE arithmetic, plus conversions between float and integer.

There is no floating square root instruction.

In addition to the operations found in conventional RISC architectures, there are conditional moves for avoiding branches, and merge sign/exponent instructions for simple field manipulation.

Rather then keeping global state bits for arithmetic trap enables and rounding mode, these enable and mode bits are encoded in the function field of each instruction.

SIGNIFICANT DIFFERENCES BETWEEN ALPHA AND CONVENTIONAL RISC PROCESSORS

First, Alpha is a true 64-bit architecture, with a minimal number of 32-bit instructions. It is not a 32-bit architecture that was later expanded to 64 bits.

Second, Alpha was designed to allow very high-speed implementations. The instructions are very simple (no load-four-registers-unaligned-and-check- for-bytes-of-zero). There are no special registers that would prevent pipelining multiple instances of the same operations (no MQ register and no condition codes). The instructions interact with each other ONLY by one instruction writing a register or memory, and another one reading from the same place. This makes it particularly easy to build implementations that issue multiple instructions every CPU cycle. (The first implementation in fact issues two instructions every cycle.) There are no implementation-specific pipeline timing hazards, no load-delay slots, and no branch-delay slots. These features would make it difficult to maintain binary compatibility across multiple implementations and difficult to maintain full speed on multiple-issue implementations.

Alpha is unconventional in the approach to byte manipulation. Single-byte stores found in conventional RISC architectures force cache and memory implementations to include byte shift-and-mask logic, and sequencer logic to perform read-modify-write on memory words. This approach is awkward to implement quickly, and tends to slow down cache access to normal 32- or 64-bit aligned quantities. It also makes it awkward to build a high-speed error-correcting write-back cache, which is often needed to keep a very fast RISC implementation busy. It also can make it difficult to pipeline multiple byte operations.

Instead, the byte shifting and masking is done in Alpha with normal 64-bit register-to-register instructions, crafted to keep the sequences short.

Alpha is also unconventional in the approach to arithmetic traps. In contrast to conventional RISC architectures, Alpha arithmetic traps (overflow, underflow, etc.) are imprecise -- they can be delivered an arbitrary number of instructions after the instruction that triggered the trap, and traps from many different instructions can be reported at once. This makes implementations that use pipelining and multiple issue substantially easier to build.

If precise arithmetic exceptions are desired, trap barrier instructions can be explicitly inserted in the program to force traps to be delivered at specific points.

Alpha is also unconventional in the approach to multiprocessor shared memory. As viewed from a second processor (including an I/O device), a sequence of reads and writes issued by one processor may be arbitrarily reordered by an implementation. This allows implementations to use multi-bank caches, bypassed write buffers, write merging, pipelined writes with retry on error, etc. If strict ordering between two accesses must be maintained, memory barrier instructions can be explicitly inserted in the program.

The basic multiprocessor interlocking primitive is a RISC-style load_locked, modify, store_conditional sequence. If the sequence runs without interrupt, exception, or an interfering write from another processor, then the conditional store succeeds. Otherwise, the store fails and the program eventually must branch back and retry the sequence. This style of interlocking scales well with very fast caches, and makes Alpha an especially attractive architecture for building multiple-processor systems.

Alpha includes a number of HINTS for implementations, all aimed at allowing higher speed. Calculated jumps have a target hint that can allow much faster subroutine calls and returns. There are prefetching hints for the memory system that can allow much higher cache hit rates. There are also granularity hints for the virtual-address mapping that can allow much more effective use of translation lookaside buffers for big contiguous structures.

Alpha includes a very flexible privileged library of software for operating- system-specific operations, invoked with PALcalls. This library allows Alpha to run full VMS using one version of this software library that mirrors many of the VAX operating-system features, and to run OSF/1 using a different version that mirrors many of the MIPS operating-system features, and similarly for NT. Other versions could be tailored for real-time, teaching, etc. The PALcalls allow Alpha to run VMS with hardly more hardware than a a conventional RISC machine has (the PAL mode bit itself, plus 4 extra protection bits in each TB entry). This library makes Alpha an especially attractive architecture for multiple operating systems.

Finally, Alpha is not strongly biased toward only one or two programming languages. It is an attractive architecture for compiling at least a dozen different languages.

SUMMARY

Alpha is designed to be a leadership 64-bit architecture.



    Specifications (150MHz version).
    Process Technology          .75 micron CMOS 
    Cycle Time                   150 MHz (6.6 ns)
    Die Size                     13.9mm x 16.8mm
    Transistor Count             1.68 million
    Package                      431 pin PGA
    Number of Signal Pins        291
    Power Dissipation            23 W at 6.6 ns cycle
    Power Supply                 3.3 volts
    Clocking Input               300 MHz differential 
    On-chip D-cache              8 Kbyte, physical, direct-mapped,
                                 write-through, 32-byte line, 32-byte fill
    On-chip I-cache              8 Kbyte, physical, direct-mapped,
                                 32-byte line, 32-byte fill, 64 ASNs
    On-chip DTB                  32-entry; fully-associative; 8-Kbyte,
                                 64-Kbyte, 256-Kbyte, 4-Mbyte page sizes
    On-chip ITB                  8-entry, fully associative, 8-Kbyte page
                                 plus 4-entry, fully-associative, 4-Mbyte page
    Floating Point Unit          On-chip FPU supports both IEEE and VAX
                                 floating point
    Bus                          Separate data and address bus.
                                 128-bit/64-bit data bus
    Serial ROM Interface         Allows the chip to directly
                                 access serial ROM
    Virtual Address Size         64 bits checked; 43 bits implemented
    Physical Address Size        34 bits implemented
    Page Size                    8 Kbytes
    Issue Rate                   2 instructions per cycle to A-box,
                                 E-box, or F-box
    Integer Pipeline             7-stage pipeline
    Floating Pipeline            10-stage pipeline

-- 
Message forwarded from
 Stefan Esser,  Institute of Nuclear Physics,  University of Cologne,  Germany
 se@IKP.Uni-Koeln.DE                                           [134.95.192.50]


IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be taken as working papers and personal rather than organizational statements. Items are printed at the discretion of the Editor based upon his judgement on the interest and relevancy to the readership. Letters, announcements, and other items of professional interest are selected on the same basis. Office of publication: The Editor of The ModulaTor is Guenter Dotzel; he can be reached by tel/fax: [removed due to abuse] or by mailto:[email deleted due to spam]


Home Site_index Contact Legal Buy_products OpenVMS_compiler Alpha_Oberon_System ModulaTor Bibliography Oberon[-2]_links Modula-2_links

Amazon.com [3KB] [Any browser]


Webdesign by www.otolo.com/webworx, 14-Nov-1998