Code Generation OSU CSE 2 April 2015 BL Compiler Structure Code - - PDF document

▶
code generation
SMART_READER_LITE
LIVE PREVIEW

Code Generation OSU CSE 2 April 2015 BL Compiler Structure Code - - PDF document

Sep 10, 2023 360 likes •924 views

1 Code Generation OSU CSE 2 April 2015 BL Compiler Structure Code Tokenizer Parser Generator string of string of abstract string of characters tokens integers program (source code) (words) (object code) The code generator

slide-1
SLIDE 1

Code Generation

2 April 2015 OSU CSE 1

slide-2
SLIDE 2

BL Compiler Structure

2 April 2015 OSU CSE 2

Code Generator Parser Tokenizer string of characters (source code) string of tokens (“words”) abstract program string of integers (object code)

The code generator is the last step.

slide-3
SLIDE 3

Executing a BL Program

  • There are two qualitatively different ways
  • ne might execute a BL program, given a

value of type Program that has been constructed from BL source code:

– Interpret the Program directly – Compile the Program into object code (“byte code”) that is executed by a virtual machine

2 April 2015 OSU CSE 3

slide-4
SLIDE 4

Executing a BL Program

  • There are two qualitatively different ways
  • ne might execute a BL program, given a

value of type Program that has been constructed from its source code:

– Interpret the Program directly – Compile the Program into object code (“byte code”) that is executed by a virtual machine

2 April 2015 OSU CSE 4

This is what the BL compiler will actually do; and this is how Java itself works (recall the JVM and its “byte codes”).

slide-5
SLIDE 5

Executing a BL Program

  • There are two qualitatively different ways
  • ne might execute a BL program, given a

value of type Program that has been constructed from its source code:

– Interpret the Program directly – Compile the Program into object code (“byte code”) that is executed by a virtual machine

2 April 2015 OSU CSE 5

Let’s first see how this might be done ...

slide-6
SLIDE 6

Time Lines of Execution

  • Directly interpreting a Program:
  • Compiling and then executing a Program:

2 April 2015 OSU CSE 6

Tokenize Parse Execute by interpreting the Program directly Tokenize Parse Generate code Execute by interpreting generated code on VM

slide-7
SLIDE 7

Time Lines of Execution

  • Directly interpreting a Program:
  • Compiling and then executing a Program:

2 April 2015 OSU CSE 7

Tokenize Parse Execute by interpreting the Program directly Tokenize Parse Generate code Execute by interpreting generated code on VM

At this point, you have a Program value to use.

slide-8
SLIDE 8

Time Lines of Execution

  • Directly interpreting a Program:
  • Compiling and then executing a Program:

2 April 2015 OSU CSE 8

Tokenize Parse Execute by interpreting the Program directly Tokenize Parse Generate code Execute by interpreting generated code on VM

“Execution-time” or “run-time” means here. “Execution-time” or “run-time” means here.

slide-9
SLIDE 9

Interpreting a Program

  • The structure of a Program and, within it,

the recursive structure of a Statement, directly dictate how to execute a Program by interpretation

  • Without contracts and other details, the

following few slides indicate the structure

  • f such code

2 April 2015 OSU CSE 9

slide-10
SLIDE 10

executeProgram

public static void executeProgram(Program p) { Statement tmpBody = p.newBody(); Map<String, Statement> tmpContext = p.newContext(); Statement body = p.replaceBody(tmpBody); Map<String, Statement> context = p.replaceContext(tmpContext); executeStatement(body, context); p.replaceBody(body); p.replaceContext(context); }

2 April 2015 OSU CSE 10

slide-11
SLIDE 11

2 April 2015 OSU CSE 11

BLOCK IF condition WHILE condition CALL instruction

s =

IF_ELSE condition

slide-12
SLIDE 12

executeStatement

public static void executeStatement(Statement s, Map<String, Statement> context) { switch (s.kind()) { case BLOCK: { for (int i = 0; i < s.lengthOfBlock(); i++) { Statement ns = s.removeFromBlock(i); executeStatement(ns, context); s.addToBlock(i, ns); } break; } case IF: {...} ... }

2 April 2015 OSU CSE 12

It’s recursive just like everything else to do with Statement; context is needed for case CALL.

slide-13
SLIDE 13

executeStatement

2 April 2015 OSU CSE 13

  • Non-BLOCK cases are different in kind:

– For IF, IF_ELSE, and WHILE, you need to decide whether the condition being tested as the BL program executes is (now) true or false

  • This requires a call to some method that knows the

state of BugsWorld, i.e., what the bug “sees”

– For CALL, you need to execute a primitive instruction, e.g., MOVE, INFECT, etc.

  • This requires a call to some method that updates

the state of BugsWorld

slide-14
SLIDE 14

The State of BugsWorld

2 April 2015 OSU CSE 14

slide-15
SLIDE 15

The State of BugsWorld

2 April 2015 OSU CSE 15

For example, when executing this bug’s Program in this state, next-is-empty is true.

slide-16
SLIDE 16

Where Is The State of BugsWorld?

2 April 2015 OSU CSE 16

The server knows about all the bugs, and can report to a client what a particular bug “sees”. A client executes a particular bug’s program, and tells the server to execute primitive instructions.

slide-17
SLIDE 17

executeStatement

2 April 2015 OSU CSE 17

  • Surprisingly, perhaps, executing a call to a

user-defined instruction is straightforward:

– You simply make a recursive call to executeStatement and pass it the body of that user-defined instruction, which is

  • btained from the context
slide-18
SLIDE 18

Compiling a Program

  • As noted earlier, we are instead going to

compile a Program, and the last step for a BL compiler is to generate code

  • The structure of a program to do this is

similar to that of an interpreter of a Program, except that it processes each Statement once rather than once every time it happens to be executed at run-time

2 April 2015 OSU CSE 18

slide-19
SLIDE 19

Code Generation

  • Code generation is translating a

Program to a linear (non-nested) structure, i.e., to a string of low-level instructions or “byte codes” of a BL virtual machine that can do the following:

– Update the state of BugsWorld – “Jump around” in the string to execute the right “byte codes” under the right conditions, depending on the state of BugsWorld

2 April 2015 OSU CSE 19

slide-20
SLIDE 20

Code Generation

  • Code generation is translating a

Program to a linear (non-nested) structure, i.e., to a string of low-level instructions or “byte codes” of a BL virtual machine that can do the following:

– Update the state of BugsWorld – “Jump around” in the string to execute the right “byte codes” under the right conditions, depending on the state of BugsWorld

2 April 2015 OSU CSE 20

Primitive BL instructions are translated into these “byte codes”.

slide-21
SLIDE 21

Code Generation

  • Code generation is translating a

Program to a linear (non-nested) structure, i.e., to a string of low-level instructions or “byte codes” of a BL virtual machine that can do the following:

– Update the state of BugsWorld – “Jump around” in the string to execute the right “byte codes” under the right conditions, depending on the state of BugsWorld

2 April 2015 OSU CSE 21

BL control constructs that check conditions are translated into these “byte codes”.

slide-22
SLIDE 22

Example Statement

IF next-is-wall THEN turnleft ELSE move END IF

2 April 2015 OSU CSE 22

IF_ELSE NEXT_IS_WALL BLOCK CALL turnleft BLOCK CALL move

Loc Instruction (symbolic name)

JUMP_IF_NOT_NEXT_IS_WALL 1 5 2 TURNLEFT 3 JUMP 4 6 5 MOVE 6 ...

slide-23
SLIDE 23

Example Statement

IF next-is-wall THEN turnleft ELSE move END IF

2 April 2015 OSU CSE 23

IF_ELSE NEXT_IS_WALL BLOCK CALL turnleft BLOCK CALL move

Loc Instruction (“byte code”)

10 1 5 2 1 3 6 4 6 5 6 ...

slide-24
SLIDE 24

BugsWorld Virtual Machine

  • The virtual machine for BugsWorld has

three main features:

– Memory – Instruction set – Program counter

2 April 2015 OSU CSE 24

slide-25
SLIDE 25

BugsWorld Virtual Machine

  • The virtual machine for BugsWorld has

three main features:

– Memory – Instruction set – Program counter

2 April 2015 OSU CSE 25

A string of integers that contains the “byte codes” generated from a Program.

slide-26
SLIDE 26

BugsWorld Virtual Machine

  • The virtual machine for BugsWorld has

three main features:

– Memory – Instruction set – Program counter

2 April 2015 OSU CSE 26

A finite set of integers that are the “byte codes” for the primitive instructions of the BugsWorld VM.

slide-27
SLIDE 27

BugsWorld Virtual Machine

  • The virtual machine for BugsWorld has

three main features:

– Memory – Instruction set – Program counter

2 April 2015 OSU CSE 27

Each instruction is given a symbolic name here, for ease

  • f reading, but the VM knows
  • nly about integer “byte codes”.
slide-28
SLIDE 28

BugsWorld Virtual Machine

  • The virtual machine for BugsWorld has

three main features:

– Memory – Instruction set – Program counter

2 April 2015 OSU CSE 28

An integer that designates the location/position/address in memory of the “byte code” to be executed next.

slide-29
SLIDE 29

BugsWorld Virtual Machine

  • The virtual machine for BugsWorld has

three main features:

– Memory – Instruction set – Program counter

2 April 2015 OSU CSE 29

Normal execution increments the program counter by 1 or 2 after each instruction, so execution proceeds sequentially.

slide-30
SLIDE 30

Instruction Set

  • The instruction set, or target language,

for code generation has two types of instructions:

– Primitive instructions – Jump instructions

2 April 2015 OSU CSE 30

slide-31
SLIDE 31

Instruction Set

  • The instruction set, or target language,

for code generation has two types of instructions:

– Primitive instructions – Jump instructions

2 April 2015 OSU CSE 31

Each of these occupies

  • ne memory location.
slide-32
SLIDE 32

Instruction Set

  • The instruction set, or target language,

for code generation has two types of instructions:

– Primitive instructions – Jump instructions

2 April 2015 OSU CSE 32

Each of these occupies two memory locations: the second one is the location to jump to.

slide-33
SLIDE 33

Primitive Instructions

  • MOVE (0)
  • TURNLEFT (1)
  • TURNRIGHT (2)
  • INFECT (3)
  • SKIP (4)
  • HALT (5)

2 April 2015 OSU CSE 33

slide-34
SLIDE 34

Primitive Instructions

  • MOVE (0)
  • TURNLEFT (1)
  • TURNRIGHT (2)
  • INFECT (3)
  • SKIP (4)
  • HALT (5)

2 April 2015 OSU CSE 34

This is the “byte code” corresponding to the symbolic name for each instruction.

slide-35
SLIDE 35

Primitive Instructions

  • MOVE (0)
  • TURNLEFT (1)
  • TURNRIGHT (2)
  • INFECT (3)
  • SKIP (4)
  • HALT (5)

2 April 2015 OSU CSE 35

This instruction halts program execution, and is the last instruction to be executed.

slide-36
SLIDE 36

Jump Instructions

  • JUMP (6)
  • JUMP_IF_NOT_NEXT_IS_EMPTY (7)
  • JUMP_IF_NOT_NEXT_IS_NOT_EMPTY (8)
  • JUMP_IF_NOT_NEXT_IS_WALL (9)
  • JUMP_IF_NOT_NEXT_IS_NOT_WALL (10)
  • JUMP_IF_NOT_NEXT_IS_FRIEND (11)
  • JUMP_IF_NOT_NEXT_IS_NOT_FRIEND (12)
  • JUMP_IF_NOT_NEXT_IS_ENEMY (13)
  • JUMP_IF_NOT_NEXT_IS_NOT_ENEMY (14)
  • JUMP_IF_NOT_RANDOM (15)
  • JUMP_IF_NOT_TRUE (16)

2 April 2015 OSU CSE 36

slide-37
SLIDE 37

Jump Instructions

  • JUMP (6)
  • JUMP_IF_NOT_NEXT_IS_EMPTY (7)
  • JUMP_IF_NOT_NEXT_IS_NOT_EMPTY (8)
  • JUMP_IF_NOT_NEXT_IS_WALL (9)
  • JUMP_IF_NOT_NEXT_IS_NOT_WALL (10)
  • JUMP_IF_NOT_NEXT_IS_FRIEND (11)
  • JUMP_IF_NOT_NEXT_IS_NOT_FRIEND (12)
  • JUMP_IF_NOT_NEXT_IS_ENEMY (13)
  • JUMP_IF_NOT_NEXT_IS_NOT_ENEMY (14)
  • JUMP_IF_NOT_RANDOM (15)
  • JUMP_IF_NOT_TRUE (16)

2 April 2015 OSU CSE 37

This unconditional jump instruction causes the program counter to be set to the value in the memory location following the JUMP.

slide-38
SLIDE 38

Jump Instructions

  • JUMP (6)
  • JUMP_IF_NOT_NEXT_IS_EMPTY (7)
  • JUMP_IF_NOT_NEXT_IS_NOT_EMPTY (8)
  • JUMP_IF_NOT_NEXT_IS_WALL (9)
  • JUMP_IF_NOT_NEXT_IS_NOT_WALL (10)
  • JUMP_IF_NOT_NEXT_IS_FRIEND (11)
  • JUMP_IF_NOT_NEXT_IS_NOT_FRIEND (12)
  • JUMP_IF_NOT_NEXT_IS_ENEMY (13)
  • JUMP_IF_NOT_NEXT_IS_NOT_ENEMY (14)
  • JUMP_IF_NOT_RANDOM (15)
  • JUMP_IF_NOT_TRUE (16)

2 April 2015 OSU CSE 38

This conditional jump instruction causes the program counter to be set to the value in the memory location following the instruction iff it is not the case that the cell in front of the bug is a wall.

slide-39
SLIDE 39

Handling an IF Statement

IF condition THEN block END IF

2 April 2015 OSU CSE 39

Loc Instruction (symbolic name)

k JUMP_IF_NOT_condition k+1 k+n+2 k+2 block (n instructions) ... k+n+1 k+n+2 ...

slide-40
SLIDE 40

Handling an IF_ELSE Statement

IF condition THEN block1 ELSE block2 END IF

2 April 2015 OSU CSE 40

Loc Instruction (symbolic name)

k JUMP_IF_NOT_condition k+1 k+n1+4 k+2 block1 (n1 instructions) ... k+n1+2 JUMP k+n1+3 k+n1+n2+4 k+n1+4 block2 (n2 instructions) ... k+n1+n2+4 ...

slide-41
SLIDE 41

Handling a WHILE Statement

WHILE condition DO block END WHILE

2 April 2015 OSU CSE 41

Loc Instruction (symbolic name)

k JUMP_IF_NOT_condition k+1 k+n+4 k+2 block (n instructions) ... k+n+2 JUMP k+n+3 k k+n+4 ...

slide-42
SLIDE 42

Handling a CALL Statement

move turnleft (etc.)

2 April 2015 OSU CSE 42

Loc Instruction (symbolic name)

k MOVE

Loc Instruction (symbolic name)

k TURNLEFT

slide-43
SLIDE 43

Handling a CALL Statement

INSTRUCTION my-instruction IS block END my-instruction my-instruction

2 April 2015 OSU CSE 43

Loc Instruction (symbolic name)

k block (of n instructions) ... k+n-1 k+n ...

slide-44
SLIDE 44

Handling a CALL Statement

INSTRUCTION my-instruction IS block END my-instruction my-instruction

2 April 2015 OSU CSE 44

Loc Instruction (symbolic name)

k block (of n instructions) ... k+n-1 k+n ...

A call to my-instruction generates a block of “byte codes” for the body of my-instruction.

slide-45
SLIDE 45

Handling a CALL Statement

INSTRUCTION my-instruction IS block END my-instruction my-instruction

2 April 2015 OSU CSE 45

Loc Instruction (symbolic name)

k block (of n instructions) ... k+n-1 k+n ...

This way of generating code for a call to a user-defined instruction is called in-lining.

slide-46
SLIDE 46

Handling a CALL Statement

INSTRUCTION my-instruction IS block END my-instruction my-instruction

2 April 2015 OSU CSE 46

Loc Instruction (symbolic name)

k block (of n instructions) ... k+n-1 k+n ...

What would happen with in-lining if BL allowed recursion? How else might you handle calls to user-defined instructions?

slide-47
SLIDE 47

Handling a BLOCK Statement

  • The “byte codes” generated for individual

Statements in a block (a sequence of Statements) are placed sequentially, one after the other, in memory

  • Remember: at the end of the body block of

the Program, there must be a HALT instruction

2 April 2015 OSU CSE 47

slide-48
SLIDE 48

Aside: More On Java enum

  • Recall: the Java enum construct allows

you to give meaningful symbolic names to values for which you might instead have used arbitrary int constants

  • This construct has some other valuable

features that allow you to associate symbolic names (e.g., for VM instructions) with specific int constants (e.g., their “byte codes”)

2 April 2015 OSU CSE 48

slide-49
SLIDE 49

The Instruction Enum

  • The interface Program contains this code:

/** * BugsWorld VM instructions and "byte codes". */ enum Instruction { MOVE(0), TURNLEFT(1), ... ; ... }

2 April 2015 OSU CSE 49

plus 15 more instructions An instance variable, a constructor, and an accessor method ...

slide-50
SLIDE 50

The Instruction Enum

  • The interface Program contains this code:

enum Instruction { MOVE(0), TURNLEFT(1), ... ; private int blByteCode; private Instruction(int code) { this.blByteCode = code; } public int byteCode() { return this.blByteCode; } }

2 April 2015 OSU CSE 50

slide-51
SLIDE 51

The Instruction Enum

  • The interface Program contains this code:

enum Instruction { MOVE(0), TURNLEFT(1), ... ; private int blByteCode; private Instruction(int code) { this.blByteCode = code; } public int byteCode() { return this.blByteCode; } }

2 April 2015 OSU CSE 51

Every Instruction (e.g., MOVE) has an int instance variable called blByteCode.

slide-52
SLIDE 52

The Instruction Enum

  • The interface Program contains this code:

enum Instruction { MOVE(0), TURNLEFT(1), ... ; private int blByteCode; private Instruction(int code) { this.blByteCode = code; } public int byteCode() { return this.blByteCode; } }

2 April 2015 OSU CSE 52

This constructor makes each Instruction’s “argument” (in parens) the value of its associated blByteCode.

slide-53
SLIDE 53

The Instruction Enum

  • The interface Program contains this code:

enum Instruction { MOVE(0), TURNLEFT(1), ... ; private int blByteCode; private Instruction(int code) { this.blByteCode = code; } public int byteCode() { return this.blByteCode; } }

2 April 2015 OSU CSE 53

This accessor method (an instance method) allows a client to access an Instruction’s associated blByteCode.

slide-54
SLIDE 54

Using This Feature

  • In client code using Instruction, one

might write something like this:

Instruction i = Instruction.TURNLEFT; ... int code = i.byteCode();

  • r even:

... Instruction.TURNLEFT.byteCode() ...

  • The “byte code” thus obtained is what

needs to be put into the generated code

2 April 2015 OSU CSE 54

slide-55
SLIDE 55

Resources

  • OSU CSE Components API: Program,

Program.Instruction

– http://cse.osu.edu/software/common/doc/

  • Java Tutorials: Enum Types

– http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

2 April 2015 OSU CSE 55