In article <4xdH5b8q3@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >What are the SPECmarks for the 88110, and at what clock speed was the >chip running? > [Warning... long explanation ahead to help avoid excessive flaming for presenting simulated performance figures.] The SPEC data that Keith presented at Microprocessor Forum was based on simulations of the 88110 at a clock speed of 50 MHz. The simulator (XSim) is an extremely accurate instruction-level model of the chip that presents timing information on a clock-by-clock basis. It models virtually every microarchitectural feature of the chip, including on-chip instruction and data caches and PATC (TLB) timing effects. External memory is modeled using user-definable parameters that specify two "delay" factors (in clocks) corresponding to the critical word off-chip memory access and subsequent "burst" accesses for the remainder of the cache line fill. The simulator has been available as a Motorola product (under non-disclosure agreement) to interested parties for well over a year now, and can execute either SVR3 (COFF) or SVR4 (ELF) binary formats. Since the simulator was developed in parallel with the chip itself, a great deal of effort was made to verify the accuracy of the simulator by comparing timing sequences with the actual chip design models. Of course, external memory and system effects are difficult/impossible to verify on chip models, which is why the external memory modeling in the simulator was designed to be fairly flexible. For the data reported below, the 88110 SPEC code was compiled using an Alpha release of the Motorola 88110 C and Fortran compilers. No "hand-tuning" or modification of assembly code took place when compiling SPEC, so the performance is truly a function of the chip/compiler/system combination, not a speadsheet. I won't go into a lot of justification/explanation of the value of simulated performance, as I think this ground was thoroughly covered a few weeks ago for the R4000. The bottom line is that we believe that we have the capability to accurately model the 88110 in software, and we have been able to make extensive use of the simulator to tune performance of the compilers. It should go without saying (but I'll say it anyway) that these numbers should not be taken as being absolutely representative of any particular implementation of an 88110 system. The limitations/features of the simulation environment should be taken into account, and ultimately, the "official" figures will be based on actual hardware. Draw your own conclusions... That being said, here are the numbers presented at Microprocessor Forum and a detailed summary of the environment used for the simulations: ------------------------------------------------------------------ Simulated 88110 SPEC Performance (SPEC Release 1.2) ------------------------------------------------------------------ (Single chip implementation @ 50 MHz; no secondary cache) gcc 46.5 espresso 48.1 spice 34.7 doduc 41.4 nasa7 67.9 xlisp 57.0 eqntott 52.9 matrix300 357.8 fpppp 64.4 tomcatv 72.2 Geometric Mean (Integer) 51.0 Geometric Mean (Flt. Pt.) 73.9 Overall simulated SPECmark: 63.7 ------------------------------------------------------------------ Notes: - All simulations based on XSim (RISCit Version 1.1) - An 88110 clock speed of 50 MHz was assumed. - On-chip caches were fully modeled in "copyback" mode. (8 Kb data, 8 Kb instruction; two-way set associativity) - No secondary cache was used. (We can approximately model an "infinite" secondary cache as 3/1 memory, but felt that the resulting performance figures would be skewed too much to be taken seriously... future releases of the simulator will include secondary cache modeling capabilities. Generally speaking, we've been seeing 20-25% improvement when a reasonably large secondary cache is used) - "Infinite" external DRAM memory was assumed. (not too bad an assumption for SPEC 1.2 on next-generation systems...) - External DRAM memory was configured as 9/1 (180 ns off-chip delay to access critical word, 20 ns for each subsequent burst access in the line fill - i.e. 9 clocks/1 clock == 9/1) - PATC (Page Address Translation Cache) misses were modeled by adding 29 clocks (= 580 ns) to the subsequent critical word memory access. This approximately simulates a "tablewalk" effect... - All benchmarks were simulated in their entirety; functional results were verified to be correct. For the xlisp and spice benchmarks, the "short" versions of the SPEC benchmarks were simulated and resultant "long" execution times were extrapolated using the ratio of long/short times on a 25 MHz DG 88100 Aviion server. (The "long" versions were simply too large to simulate in a reasonable amount of time on XSim) - All code was compiled using Motorola 88110 compilers (Alpha release 1.3) except xlisp, which was compiled using the Diab 88110 C compiler (2.37) (Strictly a performance issue...) - A prototype of the Kuck and Associates preprocessor was used in conjunction with the Motorola compilers for the matrix300 and nasa7 benchmarks. - Reported performance figures do not account for system time. (Again, we believe this to be a minor factor for the very CPU-intensive SPEC 1.2 benchmarks. Other system factors may also have a slight negative impact on actual performance). In a nutshell, we believe, from a technical point-of-view, that these numbers portray an accurate "snapshot" of where we are at in terms of 88110 compiler/chip performance. System effects that degrade performance as currently reported will likely be offset by ongoing compiler improvements. The memory system parameters were chosen to be typical of 88110 systems that are under development. Finally, in anticipation of the inevitable "that's nice, but when can we buy one?" questions, don't ask - I can't answer the question, and I doubt anyone else will, either. Flame if you want, but the choices are (a) a technical discussion of the Microprocessor Forum presentation or (b) nothing at all. I've heard valid arguments for both, so spare me, please... :^) -------------------------------------------------------------------------- Mike Phillip E-mail: phillip@oakhill.sps.mot.com RISC Compiler Development or oakhill!phillip@cs.utexas.edu Motorola, Inc. Austin, TX Phone: (512) 891-3656 -------------------------------------------------------------------------- >From article <92-02-066@comp.compilers>, by dornic@ensmp.fr (Vincent DORNIC): > Does someone knows if there exists a complete chain for the AMD 29000 > processor? It must consist in a C compiler, a linker, an emulator and a Metaware has a compiler package (C and C++). AMD offers this package along with a simulator and symbolic debugger. You should probably talk to AMD representative directly. He/She should be able to give you the necessary ordering information. Gene Yurek att!hrmsc!ejy -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. Yes, AMD offers a package, but EPI's is more complete and more customizable. I am a customer of EPI, and just purchased their system. They are in Sunnyvale or Santa Clara California. I think their number is (408) AM29000 -- mac@kpc.com -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. ---------------------------------------------------------------------- SICS has developed a fairly agressive Motorola 88100 simulator, publically available source, based around gdb. Not only then is there a code simulator but also a full debugging environment tacked on the side. The single processor slow down is around a factor of 20-30 on a SPARC station 1. The person working on the project at the moment is Peter Magnusson (psm@sics.se) , (I appologise if he has also replied to you). The simulator is based on one written by Robert Bedichek at Washington, but has been enhanced to support our multiprocessor project (the DDM machine). The simulator supports multiprocessor simulations, and also of various real devices (eg SCSI and serial I/O). In addition full symbolic debugging is possible, although I don't know if Peter has made this version availble yet (he is currently on vacation). The source code can be fetched form our ftp server: sics.se:/pub/g88 Hope this helps, best wishes, Ashley. Ashley Saulsbury Swedish Institute of Computer Science (SICS), Box 1263, 16428 Kista, Tel: +46 8 752 1570 Stockholm, Fax: +46 8 751 7230 Sweden. E-mail: ans@sics.se