Commit e97a51bb authored by sea19's avatar sea19
Browse files

Project finished and Report

parent 319ce732
\title{ARM11 - Checkpoint Report}
\author{Group 47 - \\
Samuel Andresen, Claire Shen, Christopher Kuan, \\
Jordan Emery, Sanidhya Singh}
\date{May/June 2020}
\title{ARM Checkpoint... }
\section{Group Organisation}
\section*{Work Distribution and Co-ordination}
Communication was done via a WhatsApp group for small queries and updates and
the Microsoft Teams group for meetings. While only Samuel and Claire (Siran)
attended the first meeting, Christopher participated in the project as well;
Jordan and Sanidhya were not present for any meetings and had no participation
with the project at this point. The work was split into parts based on emulator
cycles and instruction sets, with members being able to implement any part they
wanted. The emulator was mainly programmed by Samuel and Claire (Siran), where
Samuel did the implementation for the fetch and decode aspects, whilst Claire
focused on the execute aspect and also helped out a bit with the decode. Work
was also done to prepare for the assembler section, with utility functions being
partially implemented by Christopher.
\section*{Group Efficiency}
Time zone differences due to remote working made communication difficult, but
since work was separated into fairly disjoint parts and each part was able to be
taken by anyone, provided they informed the group, overall progress was still
made on the project.
\section*{Emulator Structure}
The fetch, decode and execute cycles are done in succession, with the ARM state
memory location being passed into the execute function to be altered in the
function. The decode function identifies the instruction type, and if it is a
data processing instruction, the op code is identified instead. A data struct
is used to store the instruction type and the relevant bits to be used for
execution. Then, the instruction is passed into the relevant execute function,
with each data processing op code having a separate one, and the other
instruction types having collective functions.
\section*{Potential Difficulties}
At this point, the emulator is not fully operational, but it does work for some
instructions and progress has been made on the assembler section, so work has
been eased for later sections once the emulator is completed. Also, there has
been no discussion for the extension, partially due to increased individual
workloads due to having non-participating members. - Christopher
When I tried to implement the excution part, since members in my group strated
decode and execution part at the same time and we didn't discuss the structure
of our codes before, I wasn't very clear about the structure of my codes, so I
did part of the decode in execution part(eg. the decode\_data\_processing function)
which caused difficulties later when we tried to implement pipeline function.
Also when coding the function data\_processing\_instr, there are lots of
duplicated codes which need to be improved further. And to make the file
structure more elegant, the emulator.c file also needs to be separated into a
few header files and sub-files. - Claire(Siran) Shen
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
For the first week of the project all in the group except myself and Claire were
not present. This led to a very slow start in the project, but we decided to
carry on anyway, so me and Claire(Siran) worked on the emulator, where I worked
on the fetch and decode mainly whilst Claire mainly worked on the execute
aspect. After the first group meeting Christopher showed up and started
doing work on the assembler section which has been helpful. However the rest of
the group has done nothing in the slightest to help.
\section{Implementation Strategies}
Upon creation of the group I set up a whatsapp group chat so we could coordinate
easily, which I feel has helped us three with the implementation. However,
communication about how we will implement the emulator was not really talked
about which led to large amounts of clashes in code and style when we tried to
merge them. I feel that now we are on the same page and this shows due to the
progress we have made in the past week with only 3 people. But overall, I feel
how we are working as a group of 3 now is close to optimal, only needing to add
a bit more communication between us.
Currently the Emulator is poorly structured since it is all in one file, this
is hopefully going to be changed soon, to make it easier for navigation of the
code. I feel this is very useful as a learning experience for the Assembler
section and hence we won't write all the code in one file. We will also use the
structure of how to decode the instructions in the assembler.
I feel the utility functions in the assembler may be tricky and laborious to
implement. However Christopher has already started implementing these to reduce
the amount of time it will take to program these.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
\title{ARM11 - Final Report}
\author{Group 47 - \\
Samuel Andresen, Siran Shen, Christopher Kuan, \\
Jordan Emery, Sanidhya Singh}
\date{June 2020}
\title{Our Extension...}
\section*{Assembler Structure}
The assembler is split into c files, assemble.c and assembleutils.c: assemble.c simply reads in the arguments from the command line and then finds the source file specified and creates the destination file. Whilst assembleutils.c holds all the utility functions for the assembler and is where all the calculations take place.
The assembler does two passes: one to calculate the number of instructions, and another to tokenise and write the binary code to the destination file.
In the second pass, each line is read and the mnemonic is identified, which determines which instruction set function the operands are passed to. Any stored values to be added at the end, the current address, and the number of instructions are also passed into the function, as they are needed for the single data transfer instruction set.
For data processing instructions, the function uses a switch to determine the opCode based on the mnemonic, though the MOV and testing instructions are kept in separate selection structure due to having a different bit structure and assignment.
For multiply instructions, the function only reads if the mnemonic is MLA or not, since both MUL and MLA are directed to this function and all MUL bit assignments are present in MLA, so the function only needs to assign additional bits for MLA.
For single data transfer instructions, the function takes the stored values, the number of instructions and the PC. If the offset fits in the allocated bits, then it is assigned to the result. If not, the value is stored in the stored values array to be continually passed until the end. The function also only checks for the LDR mnemonic, since it uses the same bit assignments as the STR mnemonic, with additional assignments not needed for the STR mnemonic.
For branch instructions, the current address is passed into the function and the label is found by passing through the file again, and returning the difference between the current address and the label location. If the branch has to calculate a negative offset, then it is readjusted before assignment.
For special instructions, the ANDEQ mnemonic returns 0, and the LSL mnemonic rearranges the operands before passing them to the data processing function with the MOV mnemonic and the lsl operand.
Additional helper functions were created to find the mnemonic and calculate the operand2 field. These were used to streamline the assembler by reducing clutter needed to determine the mnemonic and pass the operands to the correct instruction set function, as well reduce repeated blocks of code for calculating the operand2 field, as it is used in several data processing instructions.
A header file was used called macrosAndStructs which held all the macros and structs used in both the assembler and emulator. The macros were clearly labelled to allow for readability of the code and also to avoid 'magic numbers'. We decided that our assembler wouldn't use any structs, since the assembler would already be cluttered with selection statements.
The extension consisted of implementing, into the assembler, additional instructions: SWI, BX, SWP, SWPB, BLEQ, BLNE, BLGE, BLLT, BLGT, BLLE, BL, and the Undefined instruction. The Undefined instruction is declared outside of the mnemonic group and is returned when an unknown mnemonic is passed into the assembler. The BL (branch with link) instruction set is given its own function to generate the binary code, where it retrieves the appropriate binary form from the Branch set, and sets the Link bit to 1. The SWI (software interrupt), BX (branch and exchange), SWP and SWPB (single data swap) mnemonics are put with the special instructions and are handled in that instruction set.
\section*{Extension Difficulties}
There a few ideas to also implement the emulator for the extra instructions, but due to time constraints and absent members, this could not be done and only the assembler could be implemented. The group had planned to implement the GPIO test cases, however we felt that additional instructions took precedence since it gave more depth to the assembler, instead of adding a function for a raspberry pi.
Most of the testing was done using the ruby test server that was provided, which allowed us to ensure that we were along the right path. However since ruby only shows you the incorrect output, gdb was also used to identify errors in the code that weren't as obvious at first glance so we could then see why the output is wrong.
The extension was tested by writing source code with the new instructions and checking if the binary code outputted in the matched the expected outcome from an ARM instruction set manual in the terminal.
\section*{Group Reflection}
Despite difficulties from working remotely, like time zones and inability to meet in person, as well as non-participating members increasing the workload of all other members, work and communication was still possible through a WhatsApp chat, and barely any overlapping work was done as members were responsible enough to inform others that they were attempting a portion of the work so others would not need to attempt it. Next time, however, perhaps we would look into a more involved way to keep each other informed on our work, or having more meetings to discuss the project as a whole, possibly using Microsoft Teams.
As a group, we feel we picked up the slack that the other 2 group members left by not contributing. This was mainly done by committing to git commonly so other people could see what work someone has done. The group was not shy to criticise each other (constructively) which led to a better work ethic and faster progress, since people wouldn't only correct their mistake, they would also not repeat it which led to extremely fast learning of C and good programming etiquette.
Although communication at times when implementing the emulator was scrappy, the group learnt this and quickly fixed it. As a group the main positive would definitely be how we managed to learn quickly from our mistakes since it allowed for an acceleration in the implementation of the project and also a much better group atmosphere.
\section*{Individual Reflections}
\subsection*{Samuel Andresen}
Personally I'm very happy and proud of the work that this group has done, considering the push backs we had. As a JMC student I was worried that when the project first started I wouldn't get anywhere in the project since the workforce just didn't seem to be there for the project. However between the three of us I think we were very quick to adapt to problems, for example after the emulator we realised that we weren't communicating very well and by the end of the project I feel that the communication was close to perfect. On top of this I think my personal knowledge on how to use both git and C has greatly improved on this project.
Throughout this project, I decided to dive straight in and try and get everything to instantly work instead of striving for cleaner more efficient code. Personally I feel it may have caused, myself to spend more time later on trying to make the code better, when I could have just done it earlier and not put a larger amount of time pressure on myself and the group.
I'd personally say I was the primary contributor of the group and I really tried to help the rest when I could. I think this shows from my attendance to group meetings, creating the whatsapp group chat so people could communicate easily and my large amount of git commits to both mine and the master branch.
What I would say, is at the start of the project I feel I was very individual and tried to do it myself which in retrospect was the incorrect mentality to go into a group project with. I think if time zones weren't an issue I'd say that group calls where we code together would have been a great idea, however due to the circumstances, I feel we made close to the best out of a bad situation.
\subsection*{Siran Shen}
I felt people in the group communicate and cooperate better in the assembler part. However, I only contributed to the branch instruction so I did less work compared to the emulator part. I felt the assembler part was actually harder for me to understand which made I participate less in this section. For example, I tried to help with the branch instruction at first but it turned out my way to implement this instruction just didn't make any sense at all. So in order to be a more helpful person next time in a project, I will try harder to improve my coding skill in the future.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
\subsection*{Christopher Kuan}
I felt that, for the assembler, I was more useful than for the emulator. I think that I would prioritise learning more about how Git functioned, to make future projects easier to manage. I also think I should have started participating in the project a bit earlier, as it was a bit confusing coming in and trying to understand the code and find a way to contribute. I also had experience with video editing and LaTeX, so I knew that I could help in creating the video presentation and reports.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment