University
of
Washington


Machine
Programming
I:
Basics

  History
of
Intel
processors
and
architectures

  Intel
processors
(Wikipedia)

  Intel
microarchitectures

  C,
assembly,
machine
code

  Assembly
basics:
registers,
operands,
move
instrucAons


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 1


University
of
Washington


Intel
x86
Processors

  Totally
dominate
computer
market


  EvoluAonary
design

  Backwards
compa8ble
up
un8l
8086,
introduced
in
1978

  Added
more
features
as
8me
goes
on


  Complex
instrucAon
set
computer
(CISC)

  Many
different
instruc8ons
with
many
different
formats

But,
only
small
subset
encountered
with
Linux
programs

 
  Hard
to
match
performance
of
Reduced
Instruc8on
Set
Computers
(RISC)

  But,
Intel
has
done
just
that!


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 2

 University
of
Washington


Intel
x86
EvoluAon:
Milestones


Name 
Date 
Transistors 
MHz

  8086 
1978 
29K 
5‐10

  First
16‐bit
processor.

Basis
for
IBM
PC
&
DOS

  1MB
address
space

  386 
1985 
275K 
16‐33 


  First
32
bit
processor
,
referred
to
as
IA32

  Added
“flat
addressing”

  Capable
of
running
Unix

  32‐bit
Linux/gcc
uses
no
instruc8ons
introduced
in
later
models

  PenAum
4F 
2005 
230M 
2800‐3800

  First
64‐bit
processor

  Meanwhile,
Pen8um
4s
(Netburst
arch.)
phased
out
in
favor
of
“Core”
line

CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 3


University
of
Washington


Intel
x86
Processors:
Overview

Architectures
 Processors

X86‐16
 8086


286

X86‐32/IA32
 386

486

PenAum

MMX
 PenAum
MMX


SSE
 PenAum
III


SSE2
 PenAum
4


SSE3
 PenAum
4E

X86‐64
/
EM64t
 PenAum
4F
 Ame

Core
2
Duo

SSE4
 Core
i7


IA:
o[en
redefined
as
latest
Intel
architecture

CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 4

 University
of
Washington


Intel
x86
Processors,
contd.


  Machine
EvoluAon

  486 
1989 
1.9M 


  Pen8um 
1993 
3.1M

  Pen8um/MMX 
1997 
4.5M

  Pen8umPro 
1995 
6.5M

  Pen8um
III 
1999 
8.2M

  Pen8um
4 
2001 
42M

  Core
2
Duo 
2006 
291M

  Added
Features

  Instruc8ons
to
support
mul8media
opera8ons

  Parallel
opera8ons
on
1,
2,
and
4‐byte
data,
both
integer
&
FP

  Instruc8ons
to
enable
more
efficient
condi8onal
opera8ons

  Linux/GCC
EvoluAon

  Very
limited

CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 5


University
of
Washington


New
Species:
ia64,
then
IPF,
then
Itanium,…



Name 
Date 
Transistors

  Itanium 
2001 
10M

  First
shot
at
64‐bit
architecture:
first
called
IA64

  Radically
new
instruc8on
set
designed
for
high
performance

  Can
run
exis8ng
IA32
programs

  On‐board
“x86
engine”

  Joint
project
with
Hewleg‐Packard

  Itanium
2 
2002 
221M

  Big
performance
boost

  Itanium
2
Dual‐Core 
2006 
1.7B

  Itanium
has
not
taken
off
in
marketplace


  Lack
of
backward
compa8bility,
no
good
compiler
support,
Pen8um
4
got

too
good

CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 6

 University
of
Washington


x86
Clones:
Advanced
Micro
Devices
(AMD)

  Historically

  AMD
has
followed
just
behind
Intel

  A
ligle
bit
slower,
a
lot
cheaper

  Then

  Recruited
top
circuit
designers
from
Digital
Equipment
and
other

downward
trending
companies

  Built
Opteron:
tough
compe8tor
to
Pen8um
4

  Developed
x86‐64,
their
own
extension
to
64
bits

  Recently

  Intel
much
quicker
with
dual
core
design

  Intel
currently
far
ahead
in
performance

  em64t
backwards
compa8ble
to
x86‐64


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 7


University
of
Washington


Intel’s
64‐Bit

  Intel
Aeempted
Radical
Shi[
from
IA32
to
IA64

  Totally
different
architecture
(Itanium)

  Executes
IA32
code
only
as
legacy

  Performance
disappoin8ng

  AMD
Stepped
in
with
EvoluAonary
SoluAon

  x86‐64
(now
called
“AMD64”)

  Intel
Felt
Obligated
to
Focus
on
IA64

  Hard
to
admit
mistake
or
that
AMD
is
beger

  2004:
Intel
Announces
EM64T
extension
to
IA32

  Extended
Memory
64‐bit
Technology

  Almost
iden8cal
to
x86‐64!

  Our
Saltwater
fish
machines

  Meanwhile:
EM64t
well
introduced,


however,
sAll
o[en
not
used
by
OS,
programs

CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 8

 University
of
Washington


Our
Coverage

  IA32

  The
tradi8onal
x86


  x86‐64/EM64T

  The
emerging
standard
–
we’ll
just
touch
on
its
major
addi8ons


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 9


University
of
Washington


DefiniAons

  Architecture:
(also
instrucAon
set
architecture
or
ISA)


The
parts
of
a
processor
design
that
one
needs
to
understand

to
write
assembly
code


  Microarchitecture:
ImplementaAon
of
the
architecture


  Architecture
examples:
instrucAon
set
specificaAon,
registers

  Microarchitecture
examples:
cache
sizes
and
core
frequency


  Example
ISAs
(Intel):
x86,
IA‐32,
IPF


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 10

 University
of
Washington


Assembly
Programmer’s
View

CPU
 Memory

Addresses

PC
 Registers
 Data

Object
Code

Program
Data

CondiAon
 OS
Data

Instruc8ons

Codes

Stack

  Programmer‐Visible
State

  PC:
Program
counter

  Address
of
next
instruc8on

  Called
“EIP”
(IA32)
or
“RIP”
(x86‐64)

  Register
file

  Heavily
used
program
data
   Memory

  Byte
addressable
array

  Condi8on
codes

  Code,
user
data,
(some)
OS
data

  Store
status
informa8on
about
most

recent
arithme8c
opera8on
   Includes
stack
used
to
support

procedures
(we’ll
come
back
to
that)

  Used
for
condi8onal
branching


University
of
Washington


Turning
C
into
Object
Code

  Code
in
files
 
p1.c p2.c
  Compile
with
command:
 
gcc -O p1.c p2.c -o p
  Use
op8miza8ons
(-O)

  Put
resul8ng
binary
in
file
p


text
 C
program
(p1.c p2.c)


Compiler
(gcc -S)


text
 Asm
program
(p1.s p2.s)


Assembler
(gcc
or
as)


binary
 Object
program
(p1.o p2.o)
 StaAc
libraries
(.a)


Linker
(gcc
or ld)


binary
 Executable
program
(p)


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 12

 University
of
Washington


Compiling
Into
Assembly

C
Code
 Generated
IA32
Assembly

int sum(int x, int y) sum:
{ pushl %ebp
int t = x+y; movl %esp,%ebp
return t; movl 12(%ebp),%eax
} addl 8(%ebp),%eax
movl %ebp,%esp
popl %ebp
ret

Obtain
with
command

gcc -O -S code.c
Some
compilers
use
single

Produces
file
code.s instrucAon
“leave”


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 13


University
of
Washington


Assembly
CharacterisAcs:
Data
Types

  “Integer”
data
of
1,
2,
or
4
bytes

  Data
values

  Addresses
(untyped
pointers)


  FloaAng
point
data
of
4,
8,
or
10
bytes


  No
aggregate
types
such
as
arrays
or
structures

  Just
con8guously
allocated
bytes
in
memory


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 14

 University
of
Washington


Assembly
CharacterisAcs:
OperaAons

  Perform
arithmeAc
funcAon
on
register
or
memory
data


  Transfer
data
between
memory
and
register

  Load
data
from
memory
into
register

  Store
register
data
into
memory


  Transfer
control

  Uncondi8onal
jumps
to/from
procedures

  Condi8onal
branches


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 15


University
of
Washington


Object
Code

Code
for
sum

  Assembler

0x401040 <sum>:
0x55
  Translates
.s
into
.o
0x89   Binary
encoding
of
each
instruc8on

0xe5   Nearly‐complete
image
of
executable
code

0x8b
0x45
  Missing
linkages
between
code
in
different

0x0c files

0x03   Linker

0x45
0x08   Resolves
references
between
files

•  Total
of
13
bytes

0x89   Combines
with
sta8c
run‐8me
libraries

0xec •  Each
instrucAon

E.g.,
code
for
malloc,
printf
 
0x5d 1,
2,
or
3
bytes

0xc3 •  Starts
at
address

  Some
libraries
are
dynamically
linked

0x401040   Linking
occurs
when
program
begins

execu8on


CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 16

 University
of
Washington


Machine
InstrucAon
Example

  C
Code

int t = x+y;
  Add
two
signed
integers

  Assembly

  Add
2
4‐byte
integers

addl 8(%ebp),%eax
  “Long”
words
in
GCC
parlance

Similar
to
expression:
   Same
instruc8on
whether
signed

x += y or
unsigned

More
precisely:
   Operands:

int eax; x: 
Register 
%eax
int *ebp; y: 
Memory 
M[%ebp+8]

eax += ebp[2] t: 
Register 
%eax
– Return
func8on
value
in
%eax


0x401046: 03 45 08   Object
Code

  3‐byte
instruc8on

  Stored
at
address
0x401046
CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 17


University
of
Washington


Disassembling
Object
Code

Disassembled

00401040 <_sum>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 8b 45 0c mov 0xc(%ebp),%eax
6: 03 45 08 add 0x8(%ebp),%eax
9: 89 ec mov %ebp,%esp
b: 5d pop %ebp
c: c3 ret
d: 8d 76 00 lea 0x0(%esi),%esi

  Disassembler

objdump -d p
  Useful
tool
for
examining
object
code

  Analyzes
bit
pagern
of
series
of
instruc8ons

  Produces
approximate
rendi8on
of
assembly
code

  Can
be
run
on
either
a.out
(complete
executable)
or
.o
file

CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 18

 University
of
Washington


Alternate
Disassembly

Disassembled

Object

0x401040: 0x401040 <sum>: push %ebp
0x55 0x401041 <sum+1>: mov %esp,%ebp
0x89 0x401043 <sum+3>: mov 0xc(%ebp),%eax
0xe5 0x401046 <sum+6>: add 0x8(%ebp),%eax
0x8b 0x401049 <sum+9>: mov %ebp,%esp
0x45 0x40104b <sum+11>: pop %ebp
0x0c 0x40104c <sum+12>: ret
0x03 0x40104d <sum+13>: lea 0x0(%esi),%esi
0x45
0x08
0x89   Within
gdb
Debugger

0xec gdb p
0x5d
0xc3 disassemble sum
  Disassemble
procedure

x/13b sum
  Examine
the
13
bytes
star8ng
at
sum
CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 19


University
of
Washington


What
Can
be
Disassembled?

% objdump -d WINWORD.EXE

WINWORD.EXE: file format pei-i386

No symbols in "WINWORD.EXE".
Disassembly of section .text:

30001000 <.text>:
30001000: 55 push %ebp
30001001: 8b ec mov %esp,%ebp
30001003: 6a ff push $0xffffffff
30001005: 68 90 10 00 30 push $0x30001090
3000100a: 68 91 dc 4c 30 push $0x304cdc91

  Anything
that
can
be
interpreted
as
executable
code

  Disassembler
examines
bytes
and
reconstructs
assembly
source

CSE351
‐
Inaugural
EdiAon
‐
Spring
2010
 20

 University
of
Washington


Integer
Registers
(IA32)
 Origin

(mostly
obsolete)


%eax %ax %ah %al accumulate

%ecx %cx %ch %cl counter

%edx %dx %dh %dl data

%ebx %bx %bh %bl base

source
%esi %si index

destination
%edi %di index
stack
%esp %sp
pointer
base
%ebp %bp
pointer

16‐bit
virtual
registers

CSE351
‐
Inaugural
EdiAon
‐
Spring
2010

(backwards
compaAbility)
 21