SH3: high code density, low power

Hasegawa, Atsushi; Kawasaki, I.; Yamada, Kazuji; Yoshioka, Shinichi; Kawasaki, S.; Biswas, Partha Pratim

doi:10.1109/40.476254

Cited by 110 publications

(51 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Kozuch and Wolfe [46] measure entropy and compressibility of six different architectures (VAX, MIPS, SPARC, m68k, RS6000 and PowerPC). Hasegawa et al [3] compare SH3 code density to that of code generated by gcc on 10 other platforms (m68k, IA32, i960, Sparclite, SPARC, MIPS, AMD29k, m88k, Alpha, and RS6000). They find results roughly similar to ours, though they find the SH3 architecture generates smaller code than the x86 and m68k by a small margin.…”

Section: Density Of Compiler-generated Binariesmentioning

confidence: 99%

See 1 more Smart Citation

Code density concerns for new architectures

Weaver

McKee

2009

2009 IEEE International Conference on Computer Design

View full text Add to dashboard Cite

Abstract-Reducing a program's instruction count can improve cache behavior and bandwidth utilization, lower power consumption, and increase overall performance. Nonetheless, code density is an often overlooked feature in studying processor architectures. We hand-optimize an assembly language embedded benchmark for size on 21 different instruction set architectures, finding up to a factor of three difference in code sizes from ISA alone. We find that the architectural features that contribute most heavily to code density are instruction length, number of registers, availability of a zero register, bit-width, hardware divide units, number of instruction operands, and the availability of unaligned loads and stores.We extend our results to investigate operating system, compiler, and system library effects on code density. We find that the executable starting address, executable format, and system call interface all affect program size. While ISA effects are important, the efficiency of the entire system stack must be taken into account when developing a new dense instruction set architecture. I. BENEFITS OF CODE DENSITYDense code yields many benefits. The L1 instruction cache can hold more instructions, which usually results in fewer cache misses [1]. Less bandwidth is required to fetch instructions from memory and disk [2], and less storage is needed to hold program images. With fewer instructions, more data fits in a combined L2 cache. Also, on modern multi-threaded processors, multiple threads share limited L1 cache space, so having fewer instructions can be advantageous. Denser code causes fewer TLB misses, since the code requires fewer virtual memory pages. Modern Intel processors, for instance, can execute compact loops entirely from the instruction buffer, removing the need for L1 I-cache accesses. Finally, the ability to consistently generate denser code can conserve power, since it enables smaller microarchitectural structures and uses less bandwidthObviously, these benefits can come at a cost. For example, a denser ISA might require larger (and thus slower) pipeline decode stages, more complicated compilers, smaller logical register set sizes (due to limitations in the number of bits available in instructions), or even slower and more complex functional units. Compilers tend to optimize for performance, not size (even though the two are inextricably related): obtaining optimal code density often requires hand-tuned assembly language, which represents yet another tradeoff in terms of programmer time and maintainability. The current push for using CISC chips in the embedded market [8] forces a re-evaluation of existing ISAs. II. METHODOLOGYInvestigations of code density often use microbenchmarks (which tend to be short and not representative of actual workloads) or else industry standard benchmarks (which are written in high-level languages and thus are limited by compiler code generation capabilities). As a compromise, we take an actual system utility, but convert it into pure assembly language in order to...

show abstract

Section: Density Of Compiler-generated Binariesmentioning

confidence: 99%

“…Modern Intel processors, for instance, can execute compact loops entirely from the instruction buffer, removing the need for L1 I-cache accesses. Finally, the ability to consistently generate denser code can conserve power, since it enables smaller microarchitectural structures and uses less bandwidth [3], [4], [5], [6], [7].…”

Section: Benefits Of Code Densitymentioning

confidence: 99%

Code density concerns for new architectures

Weaver

McKee

2009

2009 IEEE International Conference on Computer Design

View full text Add to dashboard Cite

show abstract

“…To evaluate the performance of our thread library, we used cycle-accurate simulation of a multi-processor system based on the Hitachi SH embedded processor [4]. The system includes the MTSP hardware, and timers that generate interrupts for triggering dynamic map table updates.…”

Section: Discussionmentioning

confidence: 99%

Adaptive Data Placement in an Embedded Multiprocessor Thread Library

Stanley-Marbell

Lahiri

Raghunathan

2006

Proceedings of the Design Automation &Amp; Test in Europe Conference

View full text Add to dashboard Cite

Abstract-Embedded multiprocessors pose new challenges in the design and implementation of embedded software. This has led to the need for programming interfaces that expose the capabilities of the underlying hardware. In addition, for systems that implement applications consisting of multiple concurrent threads of computation, the optimized management of interthread communication is crucial for realizing high-performance. This paper presents the design of an application-adaptive thread library that conforms to the IEEE POSIX 1003.1c threading standard (Pthreads). The library adapts the placement of both explicitly marked application data objects, as well as implicitly created data objects, in a physically distributed onchip memory architecture, based on the application's data access characteristics.

show abstract

“…The phased cache divides the cache access in two phases [3]. In the first phase, it compares all tag arrays to determine whether it is a cache hit and also to find the way in which the requested data exists.…”

Section: Introductionmentioning

confidence: 99%

Way-lookup buffer for low-power set-associative cache

Lee

Kang

Lee

2011

IEICE Electron. Express

View full text Add to dashboard Cite

Abstract:The way-predicting (WP) cache is simple and energyefficient when used as L1 cache. However, a concern in the WP cache is the speed of the slow hit. This paper proposes the use of way-lookup buffer (WLB) cache to alleviate the problem of slow hit in the WP cache. The results show that the WLB slow hit is 33% faster than the WP slow hit in L1 cache. This is important because the slow hit is often the critical path that determines the processor clock cycle time. The WLB cache is as energy-efficient as the WP cache when used as L1 cache; using the WLB cache can reduce the power consumed by the conventional L1 cache by 68%. Therefore, if we like the nice properties (i.e., simplicity and energy efficiency) of the WP cache but are reluctant to use it because the slow hit extends the processor clock cycle time, then the WLB cache is the one to use.

show abstract

SH3: high code density, low power

Cited by 110 publications

References 5 publications

Code density concerns for new architectures

Code density concerns for new architectures

Adaptive Data Placement in an Embedded Multiprocessor Thread Library

Way-lookup buffer for low-power set-associative cache

Contact Info

Product

Resources

About