An analysis of MIPS and SPARC instruction set utilization on the SPEC benchmarks

Cmelik, Robert F.; Kong, Shing I.; Ditzel, David R.; Kelly, Edmund J.

doi:10.1145/106973.107001

Cited by 4 publications

(5 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, this organization is not very versatile. Although it matches well with most applications, as the SPECmark numbers for SPARCstations [6] show, different languages have different needs. As is pointed out in [21], the size of the register windows had to be reduced for the SOAR project 3 which focused on the efficient execution of Smalltalk programs, as compared to RISC I which has been designed for imperative languages like C [14].…”

Section: Introductionmentioning

confidence: 85%

A RISC processor architecture with a versatile stack system

Aßmann¹

1993

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

Modern RISC processors mainly differ w.r.t, the organization of their register files. There are currently three different approaches: a flat register file (e.g., MIPS), fixed-size register windows (SPARC), or a stack-like organization (AM20K). This paper describes a processor architecture with a new stack system, which is tailored to the needs of executing functional languages. In order to support a fast subroutine call mechanism and efficient parameter passing, our architecture uses a system of four stacks, of which two are interchangeable.A simulation of this processor architecture shows that a selection of functional benchmark programs can be executed with less machine cycles than equivalent code-optimized C programs on a SPARC or MIPS processor. keywords : RISC, processor architecture, register file, stack, functional languages.

show abstract

Section: Introductionmentioning

confidence: 85%

A RISC processor architecture with a versatile stack system

Aßmann¹

1993

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

show abstract

“…Example: Suppose we target gcc compiled in MIPS ISA for custom encoding. Statistics on instruction frequency of gcc under MIPS ISA may be found in [14]. Considering MIPS ISA has many instructions, for simplification, consider a simplified ISA consisting of just 4 instructions: int (I 1 ), load (I 2 ), store (I 3 ) and control (I 4 ).…”

Section: ) Physical Unclonable Function (Puf) and Look Up Table (Lut)mentioning

confidence: 99%

“…This gives us T = 4. For frequency analysis of these 4 instructions, we grouped all ALU instructions in [14] as int and all types of load instructions from bytes to full words are grouped into load and similarly for store and control instructions. In a real design, all sub-types of an instruction class (e.g.…”

Section: ) Physical Unclonable Function (Puf) and Look Up Table (Lut)mentioning

confidence: 99%

Preventing integrated circuit piracy via custom encoding of hardware instruction set

Patil

Vijayakumar

Kundu

2016

2016 17th International Symposium on Quality Electronic Design (ISQED)

View full text Add to dashboard Cite

Exponentially rising costs of retooling foundries and manufacturing process technology development forced many semiconductor companies to go fabless. Design, manufacturing, packaging and testing by separate companies reduce risks for individual companies through diversification, and reduces cost but creates a supply chain problem where IC designers have little control over the rest of the production chain. This makes their designs vulnerable to theft via overproduction by untrusted foundries. Various techniques like split manufacturing and hardware metering have been proposed to address the problem. They offer varying degrees of protection but require fundamental reengineering of the supply chain. In this work, we present a design flow and architecture for preventing hardware design piracy via customizing the hardware instruction set for each chip ensuring protection. An important aspect of this solution is that the customization is performed by the IC designer without upending the standard operation of the existing supply chain. We describe a design architecture based on Physically Unclonable functions for such secure customization. The results on benchmark codes demonstrate the feasibility of the system with minimal performance and hardware overheads.

show abstract

“…The SPEC benchmarks have become the standard for experimental research. Cmelik, et al used the SPECS9 suite to compare instruction set utilization on the MIPS and SPARC architectures [Cmelik91]. Numerous studies, such as [Rauch93] and [Fisher92] have used the SPEC CINT92 and CFP92 programs to study fundamental properties of application programs.…”

Section: Introductionmentioning

confidence: 99%

The effect of compiler-flag tuning on SPEC benchmark performance

Chan

Sudarsanam

Wolfe

1994

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

The SPEC CINT92 and CFP92 benchmark suites are application-based system benchmarks primarily intended for workstation-class system performance measurements. The SPEC CPU benchmark results are widely disseminated by system vendors and as such have become the de-facto standard for comparing system performance. Recently, many observers have expressed concerns about the suitability of published SPEC benchmark results in representing application performance on typical systems. The most outspoken concern is that there is too much freedom permitted in the manipulation of compiler flags. This has resulted in revisions to the SPEC reporting procedure.This paper presents and discusses many of the issues concerning the tuning of benchmarks through manipulation of compiler flags. We attempt to quantify the impact of these procedures through controlled experiments. Baseline performance results, using a set of uniform, common optimizations are compared to published data. Further experiments measure the performance of the SPEC benchmarks in the other common usage scenarios. These are a centralized file storage configuration and a system using common binaries among several implementations of the same architecture. Despite the great concern over the use of compiler flags in the SPEC community, our experiments show only a modest impact on performance. The more significant performance differential shown in the other experiments draws into question the utility of current SPEC data to many users.

show abstract

An analysis of MIPS and SPARC instruction set utilization on the SPEC benchmarks

Cited by 4 publications

References 3 publications

A RISC processor architecture with a versatile stack system

A RISC processor architecture with a versatile stack system

Preventing integrated circuit piracy via custom encoding of hardware instruction set

The effect of compiler-flag tuning on SPEC benchmark performance

Contact Info

Product

Resources

About