switches

1
switches

• java byte code supports a switch construct i.e. a
  multiway branch construct rather than the simple
  2 way branch that the if_xcmp type instructions
  support
• the value to be switched on is limited to int
  values
• there are 2 instructions - lookupswitch and
  tableswitch
• lookupswitch will pop off the int on top of the
  stack and then examine a list of key,
  label(location) pairs
• the keys form the values to be compared against
  and the label specifies the location to goto if
  the comparison value matches the key e.g.

2

• lookupswitch
• key1 label1
• key2 label2
• ....
• default defaultLabel
• default case has to be specified and always comes
  last

3

• iload_2 assume value to be switched on in
• lookupswitch local var 2 and then switch
• 1 OneLabel if value 1 goto OneLabel
• 0 ZeroLabel if value 0 goto ZeroLabel
• -1 Minuslabel if value -1 goto MinusLabel
• default DefaultLabel else goto DefaultLabel
• OneLabel
• code when 1
• ZeroLabel
• code when 0
• MinusLabel
• code when -1
• DefaultLabel
• default code

4

• tableswitch instruction requires a base value and
  a list of labels
• tableswitch ltbase valuegt
• label0
• label1
• ....
• default defaultLabel
• comparison value is still found on top of stack
  as before
• if value matches ltbase valuegt then control goes
  to label0
• thereafter if value matches ltbase valuegtN then
  execution continues from labelN i.e. (N1)th label

5

• iload_2 assume value to be switched on in
• tableswitch 1 local var 2 and then switch from
  1
• OneLabel if value 1 goto OneLabel
• TwoLabel if value 2 goto TwoLabel
• ThreeLabel if value 3 goto ThreeLabel
• default DefaultLabel else goto DefaultLabel
• OneLabel
• code when 1
• TwoLabel
• code when 2
• ThreeLabel
• code when 3
• DefaultLabel
• default code

6
Stack manipulation

• so far we have seen a number of instructions that
  push values onto and pop values off, the stack
• there are other instructions that allow us to
  directly manipulate values on the stack
• there are many occasions when you might want to
  push the same value onto the stack twice within a
  short sequence of instructions, but instead you
  can duplicate the value on the stack - it is
  faster than loading value again
• dup duplicates the value on top of the stack by
  inserting copy below top of stack

7

• WHAT WE WOULD HAVE
• DONE WITHOUT DUP
• iload_1 x in local var 1
• bipush 40
• iadd
• istore_1 x x 40
• iload_1 load x again ready
• for next instruction
• invokestatic Output/putInt (I)V

• x x 40
• putInt(x)

8

• x x 40
• putInt(x)
• stack (rightmost top of stack)
• x
• x, 40
• (x40)
• (x40), (x40)
• (x40)

• WHAT WE CAN DO WITH
• DUP
• iload_1 x in local var 1
• bipush 40
• iadd
• dup duplicate result x
• istore_1 assign to x the result
• but no need to load x
• again - value already there
• invokestatic Output/putInt (I)V

9

• there are other duplication instructions as,
• dup_x1 duplicates word on top of stack but
  inserts copy below top 2 slots
• dup_x2 duplicates word on top of stack and
  inserts copy below top 3 slots
• e.g.
• bipush 20 stack 20
• bipush 30 stack 20, 30
• dup_x1 stack 30, 20, 30

10

• there are versions of these instructions for the
  data types that take up 2 slots in the stack e.g.
  longs and doubles
• dup2 this duplicates top 2 entries on top of
  stack and places copy below the top 2 entries
• dup2_x1 duplicates top 2 entries and places
  copy below 3rd entry
• dup2_x2 duplicates top 2 entries and places
  copy below 4th entry

11

• you can simply discard the values on top of the
  stack using
• pop removes top word on stack throwing it away
• pop2 removes double word on top of stack
  throwing it away
• you can also swap the top 2 entries on the top of
  the stack
• swap stack before val1, val2
• stack after val2, val1

12
Subroutines

• As well as supporting the concept of methods java
  byte code also supports the notion of subroutines
• methods are individual routines of code that
  belong to a given object and can be invoked on
  that object or class (for static methods)
• the code for methods is self contained i.e. it is
  impossible to jump out of the byte code array for
  one method into the byte code array of another
  method

13

• however subroutines are segments of code that
  exist within the bytecode array of a method
• they allow the code to be subdivided into smaller
  units without needing the overhead of a full
  method invocation
• however they do not provide proper separation of
  subroutine code from the method whose byte code
  is using the subroutine because the segment
  actually exists as part of the method's code, and
  all the local vars that the method has access to,
  the subroutine also has access to, and you can
  jump into/out of subroutine code without
  executing a return (not good practice)

14

• subroutines in java byte code are only used to
  support special segments of code such as code
  following a finally clause - in general it
  favours using methods to define separate units of
  code
• however we will be using subroutines to implement
  separate units of code within a method like
  main()
• we will be doing this because most other low
  level programming languages do not provide a
  structuring mechanism like invokevirtual that
  handle the creation of a stack frame for the new
  method and effectively isolates the calling
  method's code from the code of the called method

15

• most other low level languages require the low
  level programmer to do such things for themselves
  by using more primitive instructions
• for this reason you will gain some experience of
  using subroutines to structure your code rather
  than methods - but you will be using methods as
  well later on

16

• new instructions that are used for subroutines
• jsr ltsubroutine labelgt
• jump to subroutine - similar to goto - the
  argument to jsr is translated by the assembler
  into an offset value (relative addressing) from
  the current value in the program counter (PC) to
  the location specified by the subroutine label
• jsr simply adds the offset value to the value in
  the PC to give the new PC value that holds the
  index in the byte code of the first instruction
  after the subroutine label

17

• however before jsr performs the addition, it
  first pushes the current value in the PC (a
  returnAddress) onto the stack
• you might imagine that you could leave the
  returnAddress on the stack for a return
  instruction to pop off the stack later - however
  this is not the case because within a subroutine
  it is possible to execute a normal method return
  and it is important to ensure that the stack does
  not have the returnAddress on the stack if that
  occurs

18

• so once the jump to the subroutine has been
  executed it is necessary to store the
  returnAddress into a local variable - using
  astore - to store a reference or address value
• so jsr has the effect
• load current PC value onto stack
• PC PC offset

19

• The other instruction required is a return
  instruction
• ret ltlocalVargt
• ret takes the value in the local var and stores
  it in the PC
• the idea is that at the end of the subroutine the
  ret instruction will force execution to continue
  with the instruction following the jsr in calling
  code

20

• template for a subroutine call
• .... some code
• load params to subroutine onto stack
• jsr subroutineName
• .... other code
• subroutineName
• astore locVar store returnAddress into local
  var
• code to do something
• ret locVar return to instruction after jsr

21
parameter passing to subroutines

• within subroutine it is possible to access the
  local vars of the enclosing method - thus any
  parameters to the subroutine could be taken
  directly from the local vars - a similar
  mechanism exists in other low level languages
  where the parameters are passed in registers
• however if you desire to maintain some separation
  between the code in the subroutine and the rest
  of the method code you could pass the values to
  be used as parameters on the stack and return
  values back to the rest of the method code using
  the stack

22

• the parameter values would then be directly acted
  upon on the stack or they could be taken off the
  stack and placed in local var slots which you
  have reserved to use only within the subroutine -
  and are not used in the code for the main part of
  the method
• passing parameters to subroutines on a stack is
  fairly standard way of passing parameters
• there is one other parameter passing method that
  is commonly used - but we will look at that in a
  later lecture

23

• .method public static main (Ljava/lang/String)V
• bipush 30 x in 1 and y in 2
• istore_2
• bipush 5
• dup dup x need it in cmp
• istore_1 x 5
• bipush 10
• if_icmpge endMethod
• iload_1 load params to
• iload_2 subroutine
• jsr subAddit call subroutine
• istore 2 y subAddit(x,y)
• endMethod
• return
• subAddit
• astore 3 store returnAddress
• iadd perform add
• ret 3 return to instr after jsr

• public static void main(String args)
• int x, y
• y 30
• x 5
• if (x lt 10)
• ysubAddit(x, y)
• return
• // NOT valid java
• subAddit(x,y)
• ret xy