# Bachelor thesis logbook Camil Staps ### 2016-09-18 Made a Vim plugin for ABC code highlighting (camilstaps/vim-abc). ARM/Thumb-2 mode switches are expensive, and since a Clean program continuously switches between the RTS and the program itself, it is not viable to have the RTS run in ARM mode and the code generator generate Thumb-2 code. Hence, I started to rewrite the RTS for Thumb-2. Mostly minor, trivial changes: - Invisible registers for some instructions (auxiliary register needed) Started to make changes to the code generator: - Added `.thumb`, `.syntax unified` to the top of each generated file - Added `.thumb_func` before each code label - Fix for the `str pc,[sp,#-4]!` and similar instructions, since `pc` cannot be the `Rd` operand in a `str` instruction: copy to scratch register first. **Question**: Is there an interface to get an auxiliary register in the code generator? For example, to swap to registers a third is necessary (or the stack, but then the PC and SP cannot be modified). In `w_as_jsr_instruction`, the PC is stored on the stack, but PC cannot be `Rd` for `str`. Therefore we need an auxiliary register (`8c91384` does this for some cases). *Answer on 09-19*. ### 2016-09-19 Talked to John: - (*Answer to question from 09-18*) Registers R14 (LR) and probably also R12 are scratch registers and can be used at any time. - When the program counter is stored on the stack in ARM (`str pc,[sp,#-4]!`), the value pushed is actually the PC + 8, which gives space for a call after storing the PC. On Thumb-2 this is different, so this should be checked. To solve the latter problem, we need to add an offset to the stored PC. Old ARM code was: ```armasm str pc,[sp,#-4]! @ Actually pushed PC+8, to after the branch. ``` First solution, since `PC` cannot be `Rd` for `str`: ```armasm mov r12,pc @ Stores PC+4 (see A5.1.2 of the ARMv7-A manual) (this is a 16-bit instruction) str r12,[sp,#-4]! @ Pushes stored value (address of THIS register) ``` New solution, with a proper offset: ```armasm add r12,pc,#9 @ Stores PC+12+1 (this is a 32-bit instruction) @ +1; bit 0 is the execution state and should be Thumb-2 str r12,[sp,#-4]! @ This is a 32-bit instruction, as is the branch below ``` After this, this program crashes only when it wants to print time information (specifically, `time_string_4`, `thumb2startup.s:929`): ```clean Start = 10 ``` The last crash has to do with alignment in `exit_clean` (`thumb2startup.s`). This indicates that `add r12,pc,#9` is not right in some cases. The second bullet point in A5.1.2 applies: > Read the word-aligned PC value, that is, the address of the current > instruction + 4, with bits [1:0] forced to zero. Hence, in some cases (when the address of the `add` instruction is 2 mod 4), we should add 11 instead of 9. A quick fix is to use `.align`, which inserts a `nop` if needed. It would be more convenient if there would be preprocessor directives like `.align` where you could yourself decide what is added depending on the current alignment (see http://stackoverflow.com/q/39582517/1544337 for this). ### 2016-09-27 See also https://community.arm.com/thread/2341 about the PC offset when reading. Started working on the actual text: wrote about - Approach: why no ARM/Thumb-2 interworking - Difficulties with storing the program counter ### 2016-10-01 **Note**: in ABC code: - `.d 1 0`: *demands* 1 argument on A-stack, 0 on B-stack - `.o 0 1 i`: *offers* 0 arguments on A-stack, 1 on B-stack with type `Int` **Problem**: instructions like `ldr pc,[sp],#4`. On the stack, program memory addresses. We need to jump to an address like that *+1* to stay in Thumb mode. Assuming every address that is stores somewhere is used like this, it is most efficient to fix this when storing the address rather than when loading it (since an address stored once may be loaded multiple times). The code generator should be adapted in `w_as_descriptor` to add 1, however, the same function is used to load pointers to data. ### 2016-10-02 **Problem**: the problem with storing the program counter was not properly fixed. In fact, it looks like the only reason it worked was some old binaries hanging around on the disk. The issue probably (**Question** for John) stems from the fact that the LSB of addresses are used by the garbage collector . Hence, storing an address with offset `#9` modifies the garbage collector information, giving incorrect results when using an up-to-date `_system.o`. **Solution**: the new solution is to store addresses with an offset of `#8`, and when jumping to an address making sure that the LSB is set (to force Thumb state). Hence, where we first had: ```armasm ldr pc,[sp],#4 ``` We now have: ```armasm ldr lr,[sp],#4 @ use lr as auxiliary register orr lr,lr,#1 @ pc cannot be left operand of orr, so orr pc,lr,#1 is not possible mov pc,lr ``` Hence, not only storing addresses is slowed down by two instructions, now also loading addresses is slowed down by two instructions. **Question** for Rinus: the solution for this problem was influenced by the fact that the Clean code generator uses the lowest two bits already. If this weren't the case, it would be more efficient to store a `#9` offset and not modify addresses when jumping. What solution should be given in the thesis? Both? **Current commits**: cg `5effb5b`, rts `0f7f68d`, tests `f7f261f`. ### 2016-10-03 Another **problem**: the Start rule `twice twice ((+) 1) 0` gives a segmentation fault. At some point it switches to ARM mode. This is probably something that should be tackled later on. **Yet another problem**: the Start rule `[]` segfaults. The issue turns out to be that for this rule, the node entry point `n1` is accidentally halfword-aligned. Hence, its bit 1 is set. This bit is used to store if a node has been reduced to (r)nf yet (not sure if rnf or nf). Therefore, it is not evaluated to `[]` properly before printing it. The **solution** to this issue is to `.align` node entry points (cg: `d9c2a69`). **New problem**: conditional instructions don't have a preceding `IT` instruction. A minimal example (borrowing some functions from StdEnv) is `Start = 1 < 2`. It seems to be resolved quite easily by adding an `IT` block (cg `9496e96`). **Question**: it is unclear to me how the instructions for `IFSGE` and `IFSLT` work. They branch, rather than move (`cgarmwas.c`): ```c case IFSGE: w_as_set_float_condition_instruction (instruction,"bpl","bmi"); ``` The generated code would then be something like: ```armasm bpl rx,#1 bmi rx,#0 ``` but what the constants are for (and if this is valid syntax) is unclear to me. **Problem**: there is no `Heap full` message. This can be verified with: ```clean fromto :: !Int !Int -> [Int] fromto a b | a > b = [] | otherwise = [a:fromto (a+1) b] Start = fromto 1 25 ``` and running with `-h 1k`. The program segfaults rather than displaying a `Heap full` message. ### 2016-10-09 The above problem (no heap full message) only occurs with the copy/compacting garbage collector (`-gcc`), not with the marking/compacting garbage collector (`gcm`). The problem seems to be that when `collect_1` returns the value in `r6` is different than before. **Question**: It seems there are whole areas of the generated binaries that are all zero (like `file_table`, where you can expect that, but also e.g. `small_integers`, should this be zero as well?) ### 2016-10-13 The problem that the copying collector segfaults has to do with `thumb2copy.s` (rts). About this file: * `continue_after_selector_2`: checks with bit 1 if the node is in rnf and jumps to `in_hnf_2` (`1`) or `not_in_hnf_2` (`0`) accordingly. * `not_in_hnf_2`: checks with bit 0 if the node has been copied to the other semispace already. If so (`1`), it jumps to `already_copied_2`. The issue above arises due to the fact that `r6`, which holds the node address, has the lowest bit set. Hence, it isn't copied. John pointed at a new **problem** that arises with a standard `append` program: ```clean append [] ys = ys append [x:xs] ys = [x:append xs ys] Start = append (fromto 1 15) (fromto 30 40) ``` This uses `fromto` from above and segfaults with `-h 1k -gcc`. In `thumb2copy.s`, `not_in_hnf_2`, the address right above the node entry point is loaded. Here, the arity is stored. This should be 2, but the generated assembly looks like: ```objdump 10f8e: 00000000 andeq r0, r0, r0 10f92: 00000002 andeq r0, r0, r2 10f96: f8dfbf00 ; 00010f98 : 10f98: f8df c030 ldr.w ip, [pc, #48] @ etc. ``` Hence, the instruction `ldr r4,[r6,#-4]` with `r6=0x10f98` reads `0xbf000000`. Note that `bf00` is `nop`. ### 2016-10-15 As suggested by John on the 13th, this is temporarily fixed by settings the lowest bit to 0 manually (rts `887b38e`). Should be fixed properly. **Idea**: if the start of a function would look like ```armasm .align .thumb_func n7: nop @ etc. ``` Then both `=n7` and `=n7+2` are good addresses to `n7`. Hence, bit 1 is free for use. On second thought, this is not necessary: when bit 1 is set, the node is in HNF, so we don't jump to it any more. ### 2016-10-16 In the branch rts:gc-flipped and cg:gc-flipped, I'm trying to not `orr lr,lr,#1` every time you want to jump to a label (to make sure you stay in Thumb mode). It seems the LSB is used only *internally* by the copying collector (see above: LSB is set iff the node is a redirection to the other semispace = iff it has been copied already). In these branches, the meaning is flipped: LSB is cleared under that condition. For nodes being used it would then be set, so we don't need to `orr`. In general the copying collector seems much more difficult than the marking collector. Consider e.g. the following programs: ```clean Start = fromto 1 100 Start = take 200 [x \\ x <- fromto 1 100000 | isEven x] Start = append (fromto 1 15) (fromto 30 40) ``` Only the first works in the gc-flipped branches with `-gcc -h 1k`, but all work with `-gcm -h 1k`.