diff --git a/docs/FutureTasks/.DS_Store b/docs/FutureTasks/.DS_Store
new file mode 100644
index 0000000..5008ddf
Binary files /dev/null and b/docs/FutureTasks/.DS_Store differ
diff --git a/docs/FutureTasks/docs.org b/docs/FutureTasks/docs.org
index e56cdb3..2341cae 100644
--- a/docs/FutureTasks/docs.org
+++ b/docs/FutureTasks/docs.org
@@ -93,3 +93,53 @@ and improving performance, especially for frequent memory operations.
 
 #+NAME: fig:MEMALLOC
 [[./memory_allocator.drawio.png]]
+
+*** Box 1
+The diagram above mentions 3 particular implementations. The first box which is the
+standard THP(Transparent huge pages) utilised by modern allocators. THP initially
+emphasises on doing smalled allocations and as the number of allocations grows
+uses a technique which groups all smaller allocations together and when done
+converts them into a large page of size 4mb in allocators such as jemalloc.
+
+This approach does incur addtional operations such as grouping smaller allocations
+chaging the TLB entries (Adding more oppurtunity for TLB misses). Only once the
+huge page is created the TLB misses are reduced.
+
+*** Box 2
+Box 2 which refers to our current implementation always pre-allocates huge pages
+and untilises CHERI bounds to track each allocation inside the huge page. Allowing
+a single entry with the combination of bounds to provide block based behavoir in
+physically contigous memory while ensuring a pointer can only access a regoin
+within it's defined bounds.
+
+Another aspect to note is that the bounds can be of a dynamic size when defined. This is
+in contrast to defining multiple page entries which need to be fixed sizes which means
+they always incur multiple entries. In the current approach when the huge page size is
+hit a new one is created. The limitaton of this is appraoch being we are limited to the
+huge page set by the processor implementation (In our case the CHERI ARM v8.1).
+
+*** Box 3
+The 3rd box specifies an alternate appraoch by not using huge pages and required
+memory is not required to be physically contigous. In this approach the pointer
+stores all the metadata to the translation from virtual to physical addresses.
+
+*** Building up from the work of Box 2 and Box 3
+Box 2 and 3 from a high overview there is only minor difference which can be noted
+which is 1 uses huge pages and other does not. Both approaches can strip down the
+number intructions needed in modern allocators (Stripping away the need transitioning
+from smaller to larger pages). This document is yet to give an exact breakdown.
+
+As seen to the right of the diagram is a sample snippet of TC malloc from the paper
+(Beyond malloc efficiency to fleet allocators). This whole span function would not
+be required in our approach. The other benefit being easier get the approach by
+getting mmap embedded inside the allocator.
+
+*** Evaluation:
+- Amount of instructions that can be stripped away from the page aware
+  memory allocator.
+- Comparing memory allocator with wall clock run time with the modified mmap and without the modified mmap.
+- CHERI purecap does incur additional instruction such as bound checks. Does this approach as a whole
+  reduce the number of instructions as whole (Comparing CHERIpurecap instructions with memory allocator
+  emitted vs regular ARMv8 clang program with the same allocator). 
+
+
diff --git a/docs/FutureTasks/docs.pdf b/docs/FutureTasks/docs.pdf
index bf0eb78..765317d 100644
Binary files a/docs/FutureTasks/docs.pdf and b/docs/FutureTasks/docs.pdf differ
diff --git a/docs/FutureTasks/docs.tex b/docs/FutureTasks/docs.tex
index af245f7..578c54d 100644
--- a/docs/FutureTasks/docs.tex
+++ b/docs/FutureTasks/docs.tex
@@ -1,4 +1,4 @@
-% Created 2025-02-24 Mon 15:33
+% Created 2025-02-25 Tue 10:21
 % Intended LaTeX compiler: pdflatex
 \documentclass[11pt]{article}
 \usepackage[utf8]{inputenc}
@@ -29,7 +29,7 @@
 
 
 \section*{Future work}
-\label{sec:org4e66dc8}
+\label{sec:org69c56b9}
 This documents is decision making to highlight
 potential paths to take for this PhD.
 We will initially talk about the current expirement
@@ -44,10 +44,10 @@ calls for larger allocators like Jemalloc.
 
 
 \subsection*{1. Current expirement: FAT pointer based range addresses}
-\label{sec:orgb9d89c6}
+\label{sec:org72b7f3a}
 \begin{center}
 \includegraphics[width=.9\linewidth]{./HighOverviewArchitecture.drawio.png}
-\label{orgb8f5fe3}
+\label{orge7449fe}
 \end{center}
 
 The objective of this expirement was to ensure we can use the CHERI bounds as
@@ -58,7 +58,7 @@ pointer using the Cheri compressed bounds mechanism. We implemented a simple
 allocator which uses this technique with a basic malloc and free.
 
 \subsubsection*{Objectives}
-\label{sec:org0ebfce1}
+\label{sec:org6aecc9c}
 \begin{itemize}
 \item How does the utilization of bounds for tracking memory
 allocations, in addition to security purposes, affect
@@ -75,13 +75,13 @@ utilization?
 \end{itemize}
 
 \subsubsection*{Hardware}
-\label{sec:org5c66697}
+\label{sec:org679e3d0}
 \begin{itemize}
 \item ARM morello (Huge page size 1GB used)
 \end{itemize}
 
 \subsubsection*{Evaluation}
-\label{sec:orga66e547}
+\label{sec:org00dd6a3}
     We conducted tests of the FAT Pointer-based range addresses against Jemalloc,
     the default memory allocator for CHERIBSD, to assess the
     performance improvements enabled by a CHERI-based huge page-aware
@@ -90,14 +90,14 @@ utilization?
     To comprehensively analyze the proposed allocator,
 we categorized benchmarks into two classes which are micro and
 macro benchmarks. Micro benchmarks comprise smaller C programs
-designed to target specific al- locator patterns, enabling us
+designed to target specific allocator patterns, enabling us
 to evaluate detailed aspects of the allocator’s behavior.
 Macro benchmarks, on the other hand, encompass larger,
 realworld C programs, allowing us to assess the allocator’s
 performance in more practical, real-world scenarios.
 
 \subsubsection*{limitation}
-\label{sec:org1aa7249}
+\label{sec:orga9c8652}
 \begin{itemize}
 \item Using Huge page still requires a TLB entry which could be mitigated
 (Refer to the FPGA work).
@@ -107,11 +107,11 @@ bypass the TLB for address translation.
 
 
 \subsection*{2. Cheri RISCV to prevent using the TLB}
-\label{sec:orgcde003a}
+\label{sec:orgff20030}
 
 \begin{center}
 \includegraphics[width=200px]{./MainOverview.png}
-\label{orgfab8f7b}
+\label{orge10034a}
 \end{center}
 
 In the current ARM Morello setup, address
@@ -128,7 +128,7 @@ implementation of a block-based allocator that can efficiently manage memory
 allocations and deallocations within defined bounds. Bypassing the TLB in RISC-V Tooba.
 
 \subsubsection*{Hardware modifications}
-\label{sec:org4c2f4f3}
+\label{sec:org684e10b}
 The Bluespec design of the RISC-V processor will be modified to allow
 certain memory operations to bypass the TLB. This means that when a pointer
 with encoded offset and bounds is used, the system can directly compute the
@@ -137,10 +137,65 @@ dependency on the TLB, decreasing latency.
 and improving performance, especially for frequent memory operations.
 
 \subsection*{3. Allocator evaluation based on stripping instruction calls for larger allocators}
-\label{sec:org08c9e01}
+\label{sec:orge8c4354}
 
 \begin{center}
 \includegraphics[width=.9\linewidth]{./memory_allocator.drawio.png}
-\label{orge9efcc8}
+\label{orgaff7895}
 \end{center}
+
+\subsubsection*{Box 1}
+\label{sec:org19bde19}
+The diagram above mentions 3 particular implementations. The first box which is the
+standard THP(Transparent huge pages) utilised by modern allocators. THP initially
+emphasises on doing smalled allocations and as the number of allocations grows
+uses a technique which groups all smaller allocations together and when done
+converts them into a large page of size 4mb in allocators such as jemalloc.
+
+This approach does incur addtional operations such as grouping smaller allocations
+chaging the TLB entries (Adding more oppurtunity for TLB misses). Only once the
+huge page is created the TLB misses are reduced.
+
+\subsubsection*{Box 2}
+\label{sec:org31e2b6f}
+Box 2 which refers to our current implementation always pre-allocates huge pages
+and untilises CHERI bounds to track each allocation inside the huge page. Allowing
+a single entry with the combination of bounds to provide block based behavoir in
+physically contigous memory while ensuring a pointer can only access a regoin
+within it's defined bounds.
+
+Another aspect to note is that the bounds can be of a dynamic size when defined. This is
+in contrast to defining multiple page entries which need to be fixed sizes which means
+they always incur multiple entries. In the current approach when the huge page size is
+hit a new one is created. The limitaton of this is appraoch being we are limited to the
+huge page set by the processor implementation (In our case the CHERI ARM v8.1).
+
+\subsubsection*{Box 3}
+\label{sec:org28e0813}
+The 3rd box specifies an alternate appraoch by not using huge pages and required
+memory is not required to be physically contigous. In this approach the pointer
+stores all the metadata to the translation from virtual to physical addresses.
+
+\subsubsection*{Building up from the work of Box 2 and Box 3}
+\label{sec:org12eb9a0}
+Box 2 and 3 from a high overview there is only minor difference which can be noted
+which is 1 uses huge pages and other does not. Both approaches can strip down the
+number intructions needed in modern allocators (Stripping away the need transitioning
+from smaller to larger pages). This document is yet to give an exact breakdown.
+
+As seen to the right of the diagram is a sample snippet of TC malloc from the paper
+(Beyond malloc efficiency to fleet allocators). This whole span function would not
+be required in our approach. The other benefit being easier get the approach by
+getting mmap embedded inside the allocator.
+
+\subsubsection*{Evaluation:}
+\label{sec:org6f6e966}
+\begin{itemize}
+\item Amount of instructions that can be stripped away from the page aware
+memory allocator.
+\item Comparing memory allocator with wall clock run time with the modified mmap and without the modified mmap.
+\item CHERI purecap does incur additional instruction such as bound checks. Does this approach as a whole
+reduce the number of instructions as whole (Comparing CHERIpurecap instructions with memory allocator
+emitted vs regular ARMv8 clang program with the same allocator).
+\end{itemize}
 \end{document}