Path: utzoo!mnetor!uunet!littlei!intelisc!omepd!mcg From: mcg@omepd (Steven McGeady) Newsgroups: comp.arch Subject: Re: Press Release: Intel announces 80960 architecture Message-ID: <3368@omepd> Date: 13 Apr 88 17:56:47 GMT References: <3358@omepd> <10320@steinmetz.ge.com> <40@radix> <11026@mimsy.UUCP> Reply-To: mcg@iwarpo3.UUCP (Steve McGeady) Organization: Intel Corp., Hillsboro Lines: 138 Keywords: 80960, RISC, embedded control I hate to present the 80960 architecture in such a peek-a-boo manner, but I have been far too busy to come up with a long diatribe (being in the engineering department rather than the marketing department). It's much easier to motivate myself to answer specific questions, so .... In article <11026@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >I took a (very) quick peek (~30 min) through an 80960 architecture >manual that showed up in our department today. It looks nice! Why, thank you. This is what we hoped for. >There are no goofy special registers beyond the usual PSL-type-thing. Namely arithmetic controls (rounding mode, fault on overflow, etc), and process controls (trace pending, supervisor mode), and trace controls (trace fault on {instruction, call, branch, return, pre-return}). >IO space access is a bit muddy to me The 80960 has no special I/O - It is entirely memory mapped. I/O registers (or whatever) can occur anywhere in the address space. The upper 16Mb of the 4Gb address space is typically reserved for processor-specific functions and I/O. >Address space is 32 bits, but branch space is smaller. (There is an >`anywhere' branch but most are 24 bit offsets.) All instructions are >32 bits so this really can cover 2^26 space (I forget whether it does, >but would seem silly not to). There are actually only 22 bits in the encoding for displacements, so, with the restriction of word-aligned instructions, the overall range is 2^24. There are branch and call-extended instructions which take absolute addresses. > Instruction data types are byte, >short (word=16 bit), long (32 bit), > `tripleword' (80 bit), and `quadword' >(128 bit), with signed and unsigned Triples are actually 96 bits, as you would suspect. They are, however, used to move 80-significant-bit extended-precision floating-point numbers around. > Signed store will trap if you try, e.g., > > ldsb addr,r3 # fetch signed byte & extend to long -128..127 > stsb addr,r3 # (r3,addr?) store it back, no trap > addo r3,$256,r3 # add ordinal: now it is in 128..347 > stsb addr,r3 # trap > Only if you have the integer overflow mask bit in the processor controls set. C programs normally clear this bit so that integer operations do not cause faults. However, we did take some care to specify the C compiler so that things would work more-or-less the way you expect them to if you had overflow faulting turned on. The "more-or-less" part means that we didn't avoid optimizations that would hide potential faults (such as constant folding in variable expressions). >As for faults, some are `indeterminate' and leave inconsistent and >hence not restartable trails, but sequencing and restartability can be >forced on a case basis (there is a `wait for pending results' >instruction) or overall (set the No Ind. Fault flag in the PSL). The >usual set of faults turns up, although integer divide by zero is >separate from F.P. divide by zero (perhaps because FP is >architecturally optional). In the current implementations (KA, KB, MC), all faults in the current implementation are 'precise', because, while the instruction stream is pipelined, potentialy imprecise faults from previous instructions are known before any irreversable actions are taken on in-progress instructions. In future implementations which execute multiple instructions per clock in parallel functional units, the fault record will contain enough information to restart most imprecise faults. The FP is indeed optional, as the KA implementation does not include it. > >FP is IEEE of course, with `plain' 32 bit real, 64 bit double, and 80 >bit `extended' precisions; there are instructions galore for (e.g.) >exp, sin, cos, tan. >Best of all :-) the assembler syntax in the examples in the manual >is Vax Unix style. .word, .align, .space directives. No more silly >ALL CAPS STUFF! Hooray! :-) > >[there, perhaps this will persuade mcg to elaborate :-) ] The tools (sans compiler) were based on the UNIX System V.3 toolset, so they should look pretty familiar to all of you. They support flexnames, portable ar format, and COFF. Interesting additions we have made include link-time leaf-procedure optimizations (turning 'call' instructions into branch-and-link instructions to preserve the stack frame cache), and 'system-call' optimizations (changing 'call' instructions into 'syscall' instructions). The toolkit includes as, ld, ar, nm, dump (COFF dumper), dis (disassembler), M4 (for those who feel they need a macro assembler), size, strip, and a ROM formatter. The compiler supports October 1987 draft ANSI (pre-noalias), including const, volatile, function prototypes, and the new C preprocessor. It has slighlty modified (but still, in our opinion, legal dpANS) floating-point widening rules to more closely model IEEE computational models, and has a 'long double' extended precision floating-point type. It also supports pre-register allocation inline assembly language support similar to the AT&T 3B2 model, which allows use of normal local and global variable names as arguments to in-lined asm functions without a need to know what registers they will be in. The compiler comes with a full (V.3) Stdio, carefully hacked to be runnable on bare hardware with underlying support only for open, close, creat, read, write, lseek, and ioctl. Libraries that support these functions for standard UARTs (for terminal I/O only) are provided. All the remaining obvious libc functions (str*, malloc, etc) are supported. Despite their System V origins, all of the tools currently run on PC-AT MS-DOS machines, and will soon be available on VAX/UNIX (Ultrix & 4.3BSD), and on VAX/VMS. In case you wonder what my involvement is, I was a member of the processor architecture group headed by Glen Myers (author of 'Advances in Computer Architecture' and other bestsellers), and later a manager of the Software Tools group. The processor was architected over a period of several years by many people who deserve much credit: among them Konrad Lai, Jim Valerio, Fred Pollack, and Dave Budde, and implemented very ably by Mike Imel, Glenn Hinton, Randy Steck, and many others. This is merely a representative, and not a comprehensive, list of the people who made the 80960 possible. Also, the 80960KB Programmer's Reference Manual is available now, and is Order Number 270567-001, and the Hardware Designer's Reference Manual is Order Number 270564-001. Both are available by calling (800) 548-4725, or by writing Intel Literature, P.O. Box 58130, Santa Clara, CA 95052-8130, or by calling your local Intel sales office. From literature sales, the manuals are $21 and $18, respectively, and I am told they are immediately available. S. McGeady Intel Corp.