Monday, October 26, 2015

Transcription

1 Monday, October 26, 2015 Topics for today Indexed branching Implementation of switch statement Reusable subroutines Indexed branching It turns out that arrays are useful in translating other language constructs, the case/switch statement for example Note that when we write BR LAB we mean BR LAB,i (the assembler lets us omit the,i for readability) From the table of Pep/8 instructions (eg, inside front cover) we see that it is also possible to write branches using indexing as in BR tab,x Q: What it the effect and why is it useful? A: The effect is to jump to whatever address is stored in Mem[tab+register X] This means we can set up a table of addresses then branch quickly to any one of them based on the value in Register X This is one way to implement a multi-way branch, eg a switch/case statement In Fig 640, Warford has an example of a switch statement translation here is a more general one: switch(w) { } case 13: case 16: < action 1 > break case 14: < action 2 > break case 11: < action 3 > break default: < action 4 > The implementation of a switch statement in Pep/8 has three components Comp 162 Notes Page 1 of 6 October 26, 2015

2 (1) implementations of the actions, with labels Each action should end with a branch to take program control to whatever statement follows the end of the switch statement This branch is the implementation of the break in the high-level example (2) A table containing the labels of the action sections Table[k] contains the label of the action we should take when the switch variable has value k or, more generally, k+constant (3) A driver section to implement the branch Here is an implementation of the example above Part 1 - the actions action1: code for whatever action 1 does goes here br endsw this branch to stop us falling into action 2 action2: other actions are similar br endsw action3: br endsw action4: br endsw Part 2 - the table The addrss directive in Pep/8 is similar to word Both have the effect of initializing a two-byte location with a value known at assembly time Since we are storing addresses, we choose to use addrss In our example, if the switch variable has value 12 or 15 we go to the default case swtab: addrss action3 case 11 addrss action4 case 12 addrss action1 case 13 addrss action2 case 14 addrss action4 case 15 addrss action1 case 16 Comp 162 Notes Page 2 of 6 October 26, 2015

3 Part 3 - the driver section ldx w,d the switch variable cpx 11,i less than the lowest switch case? brlt action4 yes do the default case cpx 16,i greater then the highest switch case? brgt action4 yes do the default case subx 11,i to get X in range of array indexes: 0 aslx to make into offset for table of (2-byte) addresses br swtab,x jump to one of the actions endsw: go here after each case Clearly this approach would not be a good one in all instances What if the switch statement were switch(w) { case 1: < action 1 > case 100: < action 2 > case 1000: < action 3 > default: < action 4 > } The array in this case would be very large and almost all the entries would point to the default case In this instance it would be better to implement the switch statement as a sequence of test-andbranch statements A compiler will apply some internal check to the case labels to decide which of the two implementations to use Indexed subroutine calls Note that CALL tab,x is also legal so we can set up a table of subroutine addresses and jump to one depending on the value on register X then return to the instruction following the CALL This might be a good way to implement a menu-driven program Something like the following perhaps Comp 162 Notes Page 3 of 6 October 26, 2015

4 main: stro prompt,d output a prompt deci choice,d get user selection brne act assume entering zero means stop stop act: ldx choice,d action number aslx subroutine addresses are 2 bytes call options,x use table of subroutine addresses br main then get next choice options:word 0 never executed corresponds to option 0 = stop address sub1 sub1 to be called if user enters 1 address sub2 sub2 to be called if user enters 2 and so on sub1: action corresponding to command 1 ret0 sub2: action corresponding to command 2 ret0 and so on Comp 162 Notes Page 4 of 6 October 26, 2015

5 Reusable subroutines We would like the subroutines we write to be usable in more than one program What are some issues that might prevent us from cutting a subroutine from one program (source) and pasting into another (target)? A couple of problems are: (1) Labels that we use in the subroutine may clash with labels already in use in the target program (2) The subroutine may interfere with the way that registers are being used in the target program, for example to control loops Possible solutions (1) We can reduce the probability of label-clash if all the labels in a subroutine begin with a common prefix However, rather than make this prefix a random string, we could base it on the name of the subroutine 1 (2) We can save the values of registers A and X on entry to the subroutine and restore them on exit We can use scratch stack space for this A third characteristic of a reusable subroutine would be commentary describing parameters, results and any assumptions made about the environment in which the subroutine is used Here is an example bitcount (pds 10/22/09) Parameter N Result: number of 1's in the (two's complement) binary representation of N Label common prefix: bitco bitcount: sta -2,s saving registers on entry stx -4,s lda 0,i to count the 1s ldx 2,s register X holds the number being tested bitcotop: breq bitcofin zero means no more 1's brgt bitcolab skip if sign bit is zero adda 1,i count of 1's incremented because sign bit is 1 bitcolab: aslx shifting number brings next bit to sign position br bitcotop bitcofin: sta 4,s count is returned as result lda -2,s restoring registers on exit ldx -4,s ret0 1 Many assembly languages have a symbol (for example, a period or asterisk) that represents the current location The symbol can be used in branch instructions avoiding the need for labels at all though making the code lees readable BR *+6 BRLT -12 Comp 162 Notes Page 5 of 6 October 26, 2015

6 Reading Case statements are covered in pages Comp 162 Notes Page 6 of 6 October 26, 2015