enhancing the move framework endianness port long immediates master’s thesis | ivo janssen | 11...

Enhancing the MOVE framework

Endianness portLong Immediates

Master’s thesis | Ivo Janssen | 11 mei 2001

Enhancing the MOVE framework - Ivo Janssen - May 11, 2001 2

introductionintroduction

immediatesimmediates

endiannessendianness

conclusionsconclusions

overview

• introduction• endianness• long immediates• conclusions







introduction

• project motivation• overview Move project







motivation

• Laboratory ofComputer Engineering

• NEC C&CRL, Princeton, NJ, USA

• PcomP / packet processor• endianness• immediates

• linux/x86 machines• cheap• little endian







the move framework

softwareframeworksoftware

frameworkhardwareframeworkhardwareframework

explorerexplorer

cost/performancecycle count

modify configuration

applicationC/C++ machine technology

description







the move framework

add r3,r8,r9

shl r3,r3,4

RISC

jump 100 4 -> shl_t

r9 -> add_tr8 -> add_o add_r -> r3

r3 -> shl_o shl_r -> r3

TTA

100 -> jump_t

C++c = a+b;

c = c<<4;

d = func100(c);

Pascalbegin

c := a+b;

c := c*16;

d := func100(c)

end;







the move framework







the move framework

4 -> shl_t

r9 -> add_tr8 -> add_o

add_r -> r3

r3 -> shl_o shl_r -> r3

4 -> shl_t

r9 -> add_tr8 -> add_oadd_r -> r3

r3 -> shl_o

100 -> jump_t

add_r -> r3

r3 -> shl_o

move bus

cycle

01234

0 1 2 3


endianness






endianness

• what is endianness• endianness in the Move

framework







what is endianness

• Gulliver’s travels• byte ordering

• 32 bit architecture• ‘byte addressable’







what is endianness

• little endian (x86, PDP-11, Alpha)least significant byte is stored at the most significant address

• big endian (Sparc, HPPA, m68k)most significant byte is stored at the most significant address

11 22 33 44memory address 00 01 02 03

44 33 22 11memory address 00 01 02 03

= 0x44332211

= 0x44332211







changing endianness

• ‘byte swap’

11 22 33 44memory address 00 01 02 03

44 33 22 11







host and target endianness

• host endianness• file on disk always has the same

endianness• ‘swap’ if host != file

• target endianness• file on disk is e.g. a binary with a

certain endianness • ‘swap’ if host != target







endianness in the Move framework

• apply principles on Move framework

• host endiannessMove framework has to run on

both little (x86) and big (sparc)

• target endiannesshost should be able to run both ‘big

move’ and ‘little move’







endianness in the front end


C/C++

gcc-movegcc-move

seq. TTA

.o

assemblerassembler

linkerlinker

bintoolsbintools

movelibraries






endianness in the back end


verification

seq. TTA

s. simulators. simulator

profile

.txt

schedulerscheduler

par. TTA

p. simulatorp. simulator

profiling

parameters

machine

immediates






immediates

• what are immediates• existing implementation• requirements• possible solutions• ‘resource variant’• ‘pseudo-move variant’• conclusions• future work







what are immediates

• immediates take lots of bits• more than available space?


dy=y-1993;

1993 sub_o

1993 -> sub_o

y -> sub_t

sub_r -> dy

2 8 6guard source destination






existing implementation

• fixed immediate fields• always writes to

‘immediate register’


1993move slot move slot move slot immediate field

guard i0 sub_o

definition

use






requirements

• possibility of no dedicated fields• short immediates stay in source

field• long immediate bits in

instruction stream• add state between ‘definition’

and ‘use’• clean code interface• must be applicable to PcomP







possible solutions

1. make move slot wider2. use multiple ‘short

immediates’ to construct large

3. schedule immediate fields in the move slots


1993move slot move slot move slot

immediate field

guard i0 sub_o






‘resource variant’


i0 -> r4

immediate bits

tim

e

LIT i0

free

busy

busy

busy

busy

free

resource table






‘resource variant’

• decoupling of def/use• no dedicated fields required• LIT tag• immediates not part of

movelist• Ifetch unit stores bits in

immediate registers• immediate registers become

part of state







scheduling algorithms

• mach-file format• data structures• algorithms







mach file formatLongImmediate{ Registers: i0 20, signed, ir_0; i1 20, signed, ir_1; i2 32, signed, ir_2; Control: {}; i0 20 : {4}; i1 20 : {5}; i0 20 : {4}, i1 20: {5}, i2 32: {4,5};}

ImmediateUnits{ i0 32, signed, ir_1; i1 20, signed, ir_2; i2 20, signed, ir_3;}







scheduling algorithms

if (immediate fits in source field)return success

elseforall (iregs) do

assign ireg socket to sourcecheck resources on iregif (possible allocation imm-use found)

tentatively claim imm-usefor (this cycle downto zero) do

check if ireg is availablecheck if LIT encodig is possibletentatively assign LIT tagif (movebuses allocatable) then break

commit imm-def and imm-usereturn success


FindImmMoveBus






benchmarks

• various mach-files:• mach.pcomp

• 6 buses, 3 imm. reg., 2 imm. ‘slots’

• mach.one• 6 buses, 1 imm. reg., 1 imm. ‘slot’

• mach.small• 3 buses, 1 imm. reg., 1 imm. ‘slot’

• mach.big• 8 buses, 2 imm. reg., 2 imm. ‘slots’

• no dedicated fields







benchmarks

• various benchmarks:• dsp-suite (arfreq, music, radproc,

edge, expand, flatten, smooth)• g722main• cjpeg, djpeg• go• compress• m88ksim







benchmarks

• metric under test:• instruction counts• also derived: code size

• prediction:• slight increase instr. count• if dedicated fields go,

huge reduction in code size







benchmark results

• instruction count increases• especially for smaller machines• 1-2% average increase

(6% for small machines)

• code size decreases• dedicated fields are ~20% of

instruction word width• code size decrease can be near

20% if dedicated fields go







‘pseudo-move variant’

• TNO-FEL needed implementation too

• paradigm shift:• ‘resource variant’:

clean code interface

• resulting in the ‘pseudo-move variant’









1993 -> sub_o

1993 -> i01993 -> i0

i0 -> r33

r33 -> sub_o

dflw(r33)

imm

edia

te o

pera

tion







• split immediate move in two operations

• schedule the immediate operation (def and use) as normal moves

• count on bypass of virtual register as optimization







qualitative comparison

‘resource variant’• one ‘move’ less added• more flexible encoding• clean code interface

‘pseudo-move variant’• importing is possible• ‘real’ moves can be scheduled

effeciently







quantitative comparison

• two completely different schedulers

• compare relative cycle counts, not absolute

• cycle count increase both about the same

• small machines:‘real’ move -> better schedule







future work

• exploration• importing of immediate

writes• sharing of immediate writes







exploration







region scheduling immediate writes


immediate bitsimmediate bits

i0 -> r4

A B

C






sharing immediate writes


i0->sub_o

i0 -> ld_t

immediate bits

tim

e

LIT i0

0

2

2

2

1

0

resource table

conclusions






conclusions endianness

• completed• host-dependency:

•sources compile onboth platforms

• target-dependency:•one Makefile switch controls

all tools







conclusions immediates

• small (negligible) instruction count increase

• possible large decrease code size

• clean code interface not entirely achieved


questions?

borrelricardishof, 21:00 uur

enhancing the move framework endianness port long immediates master’s thesis | ivo janssen | 11...

Documents