From 8ee220a5d984f83d5ee9d9eed224ab0551bc7cc3 Mon Sep 17 00:00:00 2001 From: Amlal El Mahrouss Date: Fri, 30 Jan 2026 23:43:16 +0100 Subject: feat: wg0{1..5}: some tiny refactors on the paper and ocaml scripts. Signed-off-by: Amlal El Mahrouss --- Makefile | 38 +++----- source/wg01/paper.tex | 195 +++++++++++++++++++++++++++++++++++++++++ source/wg01/wg01.tex | 195 ----------------------------------------- source/wg02/paper.tex | 170 +++++++++++++++++++++++++++++++++++ source/wg02/wg02.tex | 170 ----------------------------------- source/wg03/paper.tex | 98 +++++++++++++++++++++ source/wg03/wg03.tex | 98 --------------------- source/wg05/paper.tex | 106 ++++++++++++++++++++++ source/wg05/tn/tn001.05.tex | 79 ----------------- source/wg05/tn001.05/paper.tex | 79 +++++++++++++++++ source/wg05/wg05.tex | 106 ---------------------- tools/addentry.ml | 36 ++++++-- tools/addpaper.ml | 8 +- wg01.mk | 11 +++ wg02.mk | 11 +++ wg03.mk | 11 +++ 16 files changed, 729 insertions(+), 682 deletions(-) create mode 100644 source/wg01/paper.tex delete mode 100644 source/wg01/wg01.tex create mode 100644 source/wg02/paper.tex delete mode 100644 source/wg02/wg02.tex create mode 100644 source/wg03/paper.tex delete mode 100644 source/wg03/wg03.tex create mode 100644 source/wg05/paper.tex delete mode 100644 source/wg05/tn/tn001.05.tex create mode 100644 source/wg05/tn001.05/paper.tex delete mode 100644 source/wg05/wg05.tex create mode 100644 wg01.mk create mode 100644 wg02.mk create mode 100644 wg03.mk diff --git a/Makefile b/Makefile index 1fcc9c8..24eca4a 100644 --- a/Makefile +++ b/Makefile @@ -1,36 +1,24 @@ # File: Makefile # Author: Amlal El Mahrouss # Purpose: Generate HTML and PDF papers from LaTex documents. +# (C) 2025-2026 Amlal El Mahrouss. +# Licensed under Apache 2.0. PDFTEX ?= pdflatex -HTTEX ?= htlatex -# That one should exist honestly. +HTMLTEX ?= htlatex ECHO := @echo .PHONY: all -all: html-wg05 html-wg01 html-wg02 html-wg03 +all: wg05 wg01 wg02 wg03 $(ECHO) "=> Done building Tex files." -.PHONY: html-wg05 -html-wg05: - $(HTTEX) source/wg05/wg05.tex - $(PDFTEX) source/wg05/wg05.tex - $(HTTEX) source/wg05/tn/tn001.05.tex - $(PDFTEX) source/wg05/tn/tn001.05.tex - -.PHONY: html-wg01 -html-wg01: - $(HTTEX) source/wg01/wg01.tex - $(PDFTEX) source/wg01/wg01.tex - -.PHONY: html-wg03 -html-wg03: - $(HTTEX) source/wg03/wg03.tex - $(PDFTEX) source/wg03/wg03.tex - -.PHONY: html-wg02 -html-wg02: - $(HTTEX) source/wg02/wg02.tex - $(PDFTEX) source/wg02/wg02.tex - +include wg01.mk +include wg02.mk +include wg03.mk +.PHONY: wg05 +wg05: + $(HTMLTEX) source/wg05/paper.tex + $(PDFTEX) source/wg05/paper.tex + $(HTMLTEX) source/wg05/tn001.05/paper.tex + $(PDFTEX) source/wg05/tn001.05/paper.tex diff --git a/source/wg01/paper.tex b/source/wg01/paper.tex new file mode 100644 index 0000000..931e80b --- /dev/null +++ b/source/wg01/paper.tex @@ -0,0 +1,195 @@ +% AUTHOR: Amlal El Mahrouss +% PURPOSE: WG01: A Methodology for Freestanding Development + +\documentclass[11pt, a4paper]{article} +\usepackage{graphicx} +\usepackage{listings} +\usepackage{xcolor} +\usepackage{hyperref} +\usepackage[margin=0.5in,top=1in,bottom=1in]{geometry} + +\setlength{\columnsep}{20pt} + +\definecolor{codegray}{gray}{0.95} +\definecolor{codeblue}{rgb}{0.1,0.1,0.8} +\definecolor{codegreen}{rgb}{0,0.6,0} +\definecolor{codepurple}{rgb}{0.58,0,0.82} + +\title{Methodology for Freestanding Development.} +\author{Amlal El Mahrouss\\amlal@nekernel.org} +\date{December 2025\\Last Edited: January 2026} + +\lstset{ + language=C++, + backgroundcolor=\color{codegray}, + basicstyle=\footnotesize\ttfamily, + keywordstyle=\color{codeblue}\bfseries, + commentstyle=\color{codegreen}, + stringstyle=\color{codepurple}, + numbers=left, + numberstyle=\tiny\color{gray}, + stepnumber=1, + numbersep=5pt, + breaklines=true, + breakatwhitespace=false, + frame=single, + rulecolor=\color{black}, + captionpos=b, + keepspaces=true, + showspaces=false, + showstringspaces=false, + showtabs=false, + tabsize=2 +} + +\begin{document} + +\bf \maketitle + +\begin{center} + \rule[0.01cm]{17cm}{0.01cm} +\end{center} + +\abstract{Many low-level software have been shipped using the C programming language. +And some of them, such as EKA2 use the C++ programming language. Although notoriously difficult, one may adapt to those constraints in order to deliver one such operating system kernel. +This is why most production-grade software (Linux, XNU, and NT) are mostly written in C. With a higher-level subset in C++. However, when correctly applying the following principles to freestanding development, it becomes much easier to ensure correctness of such programs. +} + +\begin{center} + \rule[1cm]{17cm}{0.01cm} +\end{center} + +\section{The Three Principles of Freestanding Development.} +\subsection{I: The Run-Time Evaluation Domain.} +{ +The problem lies in the programming language runtime—which assumes an existing host. The contrary of a hosted environment is freestanding—a computing mode which doesn't expect a hosted runtime. Such programs may use the compile-time evaluation domain to achieve minimal run-time domain usage. +} + +\subsection{II: The Compile-Time Evaluation Domain.} +{ +One may avoid Virtual Method Tables or a runtime when possible. While focusing instead on meta-programming and compile-time features offered by C++. +For example one may use templates to implement a scheduling policy algorithm. +One example of such implementation may be: + +\begin{lstlisting} +struct FileTree final { + static constexpr bool is_virtual_memory = false; + static constexpr bool is_memory = false; + static constexpr bool is_file = true; + /// ... +}; + +struct MemoryTree final { + static constexpr bool is_virtual_memory = false; + static constexpr bool is_memory = true; + static constexpr bool is_file = false; + /// ... +}; +\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/develop/src/kernel/KernelKit/CoreProcessScheduler.h#L78-L105}{Link}. \\ Which is why the `constexpr' keyword is very powerful here for the Compile-Time Evaluation Domain, we avoid the many pitfalls of the Run-Time Evaluation Domain. + +\subsection{III: Memory Layout and the example of C++.} +{ +The Virtual Method Table (now defined as the VMT) is a big part of the problem, one may illustrate the following: + +\begin{lstlisting} +/// /std:c++20 /Wall + +#include + +class A +{ +public: + explicit A() = default; + virtual ~A() = default; + + virtual void doImpl() + { + std::cout << "doImpl()\r\n"; + } +}; + +class B : public A +{ +public: + explicit B() = default; + ~B() override = default; +}; + +int main() { + B callImpl; + callImpl.doImpl(); +} +\end{lstlisting} Source: \href{https://godbolt.org/z/aK6Y98xnd}{Link}. \\The following can instead be done to achieve similar results using the Compile-Time Evaluation Domain. + +\begin{lstlisting} +inline constexpr auto kInvalidType = 0; + +template +concept IsValidDriver = requires(Driver drv) { + { drv.IsActive() && drv.Type() > kInvalidType }; +}; +\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/develop/src/libDDK/DriverKit/c%2B%2B/driver_base.h}{Link}.\\ Now, the problem with freestanding development is that such feature may be abused, and it is mitigated by following the TTPI. + +\subsection{IV: The Three Prongs on Inheritance.} + +The TTPI is a boolean framework used to evaluate whether one may consider using a Object Oriented programming language inside a freestanding program, consider the following: + +\begin{itemize} +\item[1:] Is this implementable with compile-time protocols/concepts? +\item[2:] Is this implementable without three trade-off costs? + \subitem Without violating the Runtime cost? + \subitem The Verification cost? + \subitem The Known-Ahead-Correctness cost? +\item[3:] Is this implementable without using a VMT? +\end{itemize} +} + +\subsection{V: Compile-Time Vetting in a Freestanding Evaluation Domain.} + +The following concept makes sure that the `class T' is vetted by the domain. Such properties are called `Vettable' such program in the domain makes sure that a `Container' is truly deemed fit for a Run-Time or Compile-Time Evaluation Domain. The `Vettable' structure makes use of template meta-programming in C++ to evaluate whether a `Container' shall be vetted. Such system may look as such in a Compile-Time Evaluation Domain: + +\begin{lstlisting} +#define NE_VETTABLE static constexpr BOOL kVettable = YES; +#define NE_NON_VETTABLE static constexpr BOOL kVettable = NO; + +template +concept IsVettable = requires(Type) { + (Type::kVettable); +}; + +/// This structure is vettable. +struct Vettable { + NE_VETTABLE; +}; + +/// This structure is unvettable. +struct UnVettable { + NE_NON_VETTABLE; +}; + +/// One example of a usage. +if constexpr (IsVettable) { + instVet->Vet(); +} else { + instVet->Abort(); +} +\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/develop/src/kernel/NeKit/Vettable.h}{Link}. + +\section{VI: Conclusion} +{ Safe and correct development in a freestanding domain is indeed possible granted the above concepts are applied and respected.} + +\section{References} + +\begin{enumerate} + \item NeKernel.org (2025). NeKernel Operating System. Available at: \url{https://nekernel.org} + + \item Sales, J., Tasker, M. (2005). Introducing EKA2. Symbian OS Internals. Wiley. Available at: \url{https://media.wiley.com/product_data/excerpt/47/04700252/0470025247.pdf} + + \item Driesen, K., Hölzle, U. (1996). The direct cost of virtual function calls in C++. \textit{OOPSLA '96}. ACM. DOI: 10.1145/236338.236369 + + \item El Mahrouss, A. (2026). Methodology for Process and Image Computation. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362503 + + \item El Mahrouss, A. (2026). The Execution Semantics: On Axioms, Domains, and Authority. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362375 +\end{enumerate} + +\end{document} diff --git a/source/wg01/wg01.tex b/source/wg01/wg01.tex deleted file mode 100644 index 931e80b..0000000 --- a/source/wg01/wg01.tex +++ /dev/null @@ -1,195 +0,0 @@ -% AUTHOR: Amlal El Mahrouss -% PURPOSE: WG01: A Methodology for Freestanding Development - -\documentclass[11pt, a4paper]{article} -\usepackage{graphicx} -\usepackage{listings} -\usepackage{xcolor} -\usepackage{hyperref} -\usepackage[margin=0.5in,top=1in,bottom=1in]{geometry} - -\setlength{\columnsep}{20pt} - -\definecolor{codegray}{gray}{0.95} -\definecolor{codeblue}{rgb}{0.1,0.1,0.8} -\definecolor{codegreen}{rgb}{0,0.6,0} -\definecolor{codepurple}{rgb}{0.58,0,0.82} - -\title{Methodology for Freestanding Development.} -\author{Amlal El Mahrouss\\amlal@nekernel.org} -\date{December 2025\\Last Edited: January 2026} - -\lstset{ - language=C++, - backgroundcolor=\color{codegray}, - basicstyle=\footnotesize\ttfamily, - keywordstyle=\color{codeblue}\bfseries, - commentstyle=\color{codegreen}, - stringstyle=\color{codepurple}, - numbers=left, - numberstyle=\tiny\color{gray}, - stepnumber=1, - numbersep=5pt, - breaklines=true, - breakatwhitespace=false, - frame=single, - rulecolor=\color{black}, - captionpos=b, - keepspaces=true, - showspaces=false, - showstringspaces=false, - showtabs=false, - tabsize=2 -} - -\begin{document} - -\bf \maketitle - -\begin{center} - \rule[0.01cm]{17cm}{0.01cm} -\end{center} - -\abstract{Many low-level software have been shipped using the C programming language. -And some of them, such as EKA2 use the C++ programming language. Although notoriously difficult, one may adapt to those constraints in order to deliver one such operating system kernel. -This is why most production-grade software (Linux, XNU, and NT) are mostly written in C. With a higher-level subset in C++. However, when correctly applying the following principles to freestanding development, it becomes much easier to ensure correctness of such programs. -} - -\begin{center} - \rule[1cm]{17cm}{0.01cm} -\end{center} - -\section{The Three Principles of Freestanding Development.} -\subsection{I: The Run-Time Evaluation Domain.} -{ -The problem lies in the programming language runtime—which assumes an existing host. The contrary of a hosted environment is freestanding—a computing mode which doesn't expect a hosted runtime. Such programs may use the compile-time evaluation domain to achieve minimal run-time domain usage. -} - -\subsection{II: The Compile-Time Evaluation Domain.} -{ -One may avoid Virtual Method Tables or a runtime when possible. While focusing instead on meta-programming and compile-time features offered by C++. -For example one may use templates to implement a scheduling policy algorithm. -One example of such implementation may be: - -\begin{lstlisting} -struct FileTree final { - static constexpr bool is_virtual_memory = false; - static constexpr bool is_memory = false; - static constexpr bool is_file = true; - /// ... -}; - -struct MemoryTree final { - static constexpr bool is_virtual_memory = false; - static constexpr bool is_memory = true; - static constexpr bool is_file = false; - /// ... -}; -\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/develop/src/kernel/KernelKit/CoreProcessScheduler.h#L78-L105}{Link}. \\ Which is why the `constexpr' keyword is very powerful here for the Compile-Time Evaluation Domain, we avoid the many pitfalls of the Run-Time Evaluation Domain. - -\subsection{III: Memory Layout and the example of C++.} -{ -The Virtual Method Table (now defined as the VMT) is a big part of the problem, one may illustrate the following: - -\begin{lstlisting} -/// /std:c++20 /Wall - -#include - -class A -{ -public: - explicit A() = default; - virtual ~A() = default; - - virtual void doImpl() - { - std::cout << "doImpl()\r\n"; - } -}; - -class B : public A -{ -public: - explicit B() = default; - ~B() override = default; -}; - -int main() { - B callImpl; - callImpl.doImpl(); -} -\end{lstlisting} Source: \href{https://godbolt.org/z/aK6Y98xnd}{Link}. \\The following can instead be done to achieve similar results using the Compile-Time Evaluation Domain. - -\begin{lstlisting} -inline constexpr auto kInvalidType = 0; - -template -concept IsValidDriver = requires(Driver drv) { - { drv.IsActive() && drv.Type() > kInvalidType }; -}; -\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/develop/src/libDDK/DriverKit/c%2B%2B/driver_base.h}{Link}.\\ Now, the problem with freestanding development is that such feature may be abused, and it is mitigated by following the TTPI. - -\subsection{IV: The Three Prongs on Inheritance.} - -The TTPI is a boolean framework used to evaluate whether one may consider using a Object Oriented programming language inside a freestanding program, consider the following: - -\begin{itemize} -\item[1:] Is this implementable with compile-time protocols/concepts? -\item[2:] Is this implementable without three trade-off costs? - \subitem Without violating the Runtime cost? - \subitem The Verification cost? - \subitem The Known-Ahead-Correctness cost? -\item[3:] Is this implementable without using a VMT? -\end{itemize} -} - -\subsection{V: Compile-Time Vetting in a Freestanding Evaluation Domain.} - -The following concept makes sure that the `class T' is vetted by the domain. Such properties are called `Vettable' such program in the domain makes sure that a `Container' is truly deemed fit for a Run-Time or Compile-Time Evaluation Domain. The `Vettable' structure makes use of template meta-programming in C++ to evaluate whether a `Container' shall be vetted. Such system may look as such in a Compile-Time Evaluation Domain: - -\begin{lstlisting} -#define NE_VETTABLE static constexpr BOOL kVettable = YES; -#define NE_NON_VETTABLE static constexpr BOOL kVettable = NO; - -template -concept IsVettable = requires(Type) { - (Type::kVettable); -}; - -/// This structure is vettable. -struct Vettable { - NE_VETTABLE; -}; - -/// This structure is unvettable. -struct UnVettable { - NE_NON_VETTABLE; -}; - -/// One example of a usage. -if constexpr (IsVettable) { - instVet->Vet(); -} else { - instVet->Abort(); -} -\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/develop/src/kernel/NeKit/Vettable.h}{Link}. - -\section{VI: Conclusion} -{ Safe and correct development in a freestanding domain is indeed possible granted the above concepts are applied and respected.} - -\section{References} - -\begin{enumerate} - \item NeKernel.org (2025). NeKernel Operating System. Available at: \url{https://nekernel.org} - - \item Sales, J., Tasker, M. (2005). Introducing EKA2. Symbian OS Internals. Wiley. Available at: \url{https://media.wiley.com/product_data/excerpt/47/04700252/0470025247.pdf} - - \item Driesen, K., Hölzle, U. (1996). The direct cost of virtual function calls in C++. \textit{OOPSLA '96}. ACM. DOI: 10.1145/236338.236369 - - \item El Mahrouss, A. (2026). Methodology for Process and Image Computation. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362503 - - \item El Mahrouss, A. (2026). The Execution Semantics: On Axioms, Domains, and Authority. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362375 -\end{enumerate} - -\end{document} diff --git a/source/wg02/paper.tex b/source/wg02/paper.tex new file mode 100644 index 0000000..4f49ab5 --- /dev/null +++ b/source/wg02/paper.tex @@ -0,0 +1,170 @@ +% AUTHOR: Amlal El Mahrouss +% PURPOSE: WG02: Methodology for Process and Image Computation. + +\documentclass[11pt, a4paper]{article} +\usepackage{graphicx} +\usepackage{listings} +\usepackage{xcolor} +\usepackage{hyperref} +\usepackage[margin=0.5in,top=1in,bottom=1in]{geometry} + +\title{Methodology for Process and Image Computation.} +\author{Amlal El Mahrouss\\amlal@nekernel.org} +\date{December 2025\\Last Edited: January 2026} + +\definecolor{codegray}{gray}{0.95} +\definecolor{codeblue}{rgb}{0.1,0.1,0.8} +\definecolor{codegreen}{rgb}{0,0.6,0} +\definecolor{codepurple}{rgb}{0.58,0,0.82} + +\lstset{ + language=C++, + backgroundcolor=\color{codegray}, + basicstyle=\footnotesize\ttfamily, + keywordstyle=\color{codeblue}\bfseries, + commentstyle=\color{codegreen}, + stringstyle=\color{codepurple}, + numbers=left, + numberstyle=\tiny\color{gray}, + stepnumber=1, + numbersep=5pt, + breaklines=true, + breakatwhitespace=false, + frame=single, + rulecolor=\color{black}, + captionpos=b, + keepspaces=true, + showspaces=false, + showstringspaces=false, + showtabs=false, + tabsize=2 +} + +\begin{document} + +\bf \maketitle + +\begin{center} + \rule[0.01cm]{17cm}{0.01cm} +\end{center} + +\abstract +{CoreProcessScheduler governs how the scheduling backend and policy of the system works, It is the common gateway for schedulers inside NeKernel based systems.} + +\begin{center} + \rule[1cm]{17cm}{0.01cm} +\end{center} + +\section{I: Introduction.} + +{CoreProcessScheduler (now referred as CPS) serves as the foundation between the scheduler backend and system.} {It takes care of process life-cycle management, team-based process grouping, and affinity-based CPU based allocation to mention the least.} + +\subsection{II: The Affinity System.} + +{Processes are given CPU time affinity hints using an affinity kind type, these hints help the scheduler run or adjust the current process.} + +\subsection{Illustration: The Affinity Kind.} + +{The following sample is C++ code.} {The smaller the value, the more critical the process.} + +\begin{lstlisting} +enum struct AffinityKind : Int32 { + kRealTime = 100, + kVeryHigh = 150, + kHigh = 200, + kStandard = 1000, + kLowUsage = 1500, + kVeryLowUsage = 2000, +}; +\end{lstlisting} + +\subsection{III: The Team Domain System.} + +{The team system holds process metadata for the backend scheduler to run on. It holds methods and fields for backend specific operations.} {One implementation of such team is the UserProcessTeam object inside NeKernel.} + +\subsection{Illustration: Team System.} + +{The following sample is used to hold team metadata.} {This is part of the NeKernel source tree.} + +\begin{lstlisting} +class UserProcessTeam final { + public: + explicit UserProcessTeam(); + ~UserProcessTeam() = default; + + NE_COPY_DEFAULT(UserProcessTeam) + + Array& AsArray(); + Ref& AsRef(); + ProcessID& Id() noexcept; + + public: + UserProcessArray mProcessList; + UserProcessRef mCurrentProcess; + ProcessID mTeamId{0}; + ProcessID mProcessCur{0}; +}; +\end{lstlisting} + +\subsection{IV: The Process Image System} + +{The `ProcessImage' container is a system designed to contain process data, and metadata, its purpose comes from the need to separate data and code. Such usage is useful for validation and vettability.} {This approach helps separate concerns and give modularity to the system, as the image and process structure are not mixed together.} + +\subsection{Illustration: Process Image System.} + +{The following sample is a container used to hold process data and metadata.} {This is part of the NeKernel source tree.} + +\begin{lstlisting} +using ImagePtr = VoidPtr; + +struct ProcessImage final { + explicit ProcessImage() = default; + + private: + friend UserProcess; + friend KernelTask; + + friend class UserProcessScheduler; + + ImagePtr fCode; + ImagePtr fBlob; + + public: + Bool HasCode() const { return this->fCode != nullptr; } + + Bool HasImage() const { return this->fBlob != nullptr; } + + ErrorOr LeakImage() { + if (this->fCode) { + return ErrorOr{this->fCode}; + } + } + + ErrorOr LeakBlob() { + if (this->fBlob) { + return ErrorOr{this->fBlob}; + } + } +}; +\end{lstlisting} + +\section{V: Conclusion.} + +{The CPS is a system with provable domains and separation of computation, it governs how a Process Domain shall compute its child processes, it does not provide the algorithms.} {Which is why, one scheduler backend (such as the UserProcessScheduler) takes care of user process scheduling and fairness.} + +\section{References} + +\begin{enumerate} + \item CoreProcessScheduler.h (2025), \href{https://github.com/nekernel-org/nekernel/blob/develop/src/kernel/KernelKit/CoreProcessScheduler.h}{github.com} + + \item NeKernel.org (2025), \href{https://nekernel.org/nekernel}{nekernel.org} + \item Scheduling: Introduction (2012), \href{https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched.pdf}{pages.cs.wisc.edu} + + \item Processor Affinity, Multiple CPU Scheduling (2003), \href{https://www.tmurgent.com/WhitePapers/ProcessorAffinity.pdf}{tmurgent.com} + + \item El Mahrouss, A. (2026). Methodology for Freestanding Development.\\ Zenodo. https://doi.org/10.5281/zenodo.18362425 + + \item El Mahrouss, A. (2026). The Execution Semantics: On Axioms, Domains, and Authority. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362375 +\end{enumerate} + +\end{document} \ No newline at end of file diff --git a/source/wg02/wg02.tex b/source/wg02/wg02.tex deleted file mode 100644 index 4f49ab5..0000000 --- a/source/wg02/wg02.tex +++ /dev/null @@ -1,170 +0,0 @@ -% AUTHOR: Amlal El Mahrouss -% PURPOSE: WG02: Methodology for Process and Image Computation. - -\documentclass[11pt, a4paper]{article} -\usepackage{graphicx} -\usepackage{listings} -\usepackage{xcolor} -\usepackage{hyperref} -\usepackage[margin=0.5in,top=1in,bottom=1in]{geometry} - -\title{Methodology for Process and Image Computation.} -\author{Amlal El Mahrouss\\amlal@nekernel.org} -\date{December 2025\\Last Edited: January 2026} - -\definecolor{codegray}{gray}{0.95} -\definecolor{codeblue}{rgb}{0.1,0.1,0.8} -\definecolor{codegreen}{rgb}{0,0.6,0} -\definecolor{codepurple}{rgb}{0.58,0,0.82} - -\lstset{ - language=C++, - backgroundcolor=\color{codegray}, - basicstyle=\footnotesize\ttfamily, - keywordstyle=\color{codeblue}\bfseries, - commentstyle=\color{codegreen}, - stringstyle=\color{codepurple}, - numbers=left, - numberstyle=\tiny\color{gray}, - stepnumber=1, - numbersep=5pt, - breaklines=true, - breakatwhitespace=false, - frame=single, - rulecolor=\color{black}, - captionpos=b, - keepspaces=true, - showspaces=false, - showstringspaces=false, - showtabs=false, - tabsize=2 -} - -\begin{document} - -\bf \maketitle - -\begin{center} - \rule[0.01cm]{17cm}{0.01cm} -\end{center} - -\abstract -{CoreProcessScheduler governs how the scheduling backend and policy of the system works, It is the common gateway for schedulers inside NeKernel based systems.} - -\begin{center} - \rule[1cm]{17cm}{0.01cm} -\end{center} - -\section{I: Introduction.} - -{CoreProcessScheduler (now referred as CPS) serves as the foundation between the scheduler backend and system.} {It takes care of process life-cycle management, team-based process grouping, and affinity-based CPU based allocation to mention the least.} - -\subsection{II: The Affinity System.} - -{Processes are given CPU time affinity hints using an affinity kind type, these hints help the scheduler run or adjust the current process.} - -\subsection{Illustration: The Affinity Kind.} - -{The following sample is C++ code.} {The smaller the value, the more critical the process.} - -\begin{lstlisting} -enum struct AffinityKind : Int32 { - kRealTime = 100, - kVeryHigh = 150, - kHigh = 200, - kStandard = 1000, - kLowUsage = 1500, - kVeryLowUsage = 2000, -}; -\end{lstlisting} - -\subsection{III: The Team Domain System.} - -{The team system holds process metadata for the backend scheduler to run on. It holds methods and fields for backend specific operations.} {One implementation of such team is the UserProcessTeam object inside NeKernel.} - -\subsection{Illustration: Team System.} - -{The following sample is used to hold team metadata.} {This is part of the NeKernel source tree.} - -\begin{lstlisting} -class UserProcessTeam final { - public: - explicit UserProcessTeam(); - ~UserProcessTeam() = default; - - NE_COPY_DEFAULT(UserProcessTeam) - - Array& AsArray(); - Ref& AsRef(); - ProcessID& Id() noexcept; - - public: - UserProcessArray mProcessList; - UserProcessRef mCurrentProcess; - ProcessID mTeamId{0}; - ProcessID mProcessCur{0}; -}; -\end{lstlisting} - -\subsection{IV: The Process Image System} - -{The `ProcessImage' container is a system designed to contain process data, and metadata, its purpose comes from the need to separate data and code. Such usage is useful for validation and vettability.} {This approach helps separate concerns and give modularity to the system, as the image and process structure are not mixed together.} - -\subsection{Illustration: Process Image System.} - -{The following sample is a container used to hold process data and metadata.} {This is part of the NeKernel source tree.} - -\begin{lstlisting} -using ImagePtr = VoidPtr; - -struct ProcessImage final { - explicit ProcessImage() = default; - - private: - friend UserProcess; - friend KernelTask; - - friend class UserProcessScheduler; - - ImagePtr fCode; - ImagePtr fBlob; - - public: - Bool HasCode() const { return this->fCode != nullptr; } - - Bool HasImage() const { return this->fBlob != nullptr; } - - ErrorOr LeakImage() { - if (this->fCode) { - return ErrorOr{this->fCode}; - } - } - - ErrorOr LeakBlob() { - if (this->fBlob) { - return ErrorOr{this->fBlob}; - } - } -}; -\end{lstlisting} - -\section{V: Conclusion.} - -{The CPS is a system with provable domains and separation of computation, it governs how a Process Domain shall compute its child processes, it does not provide the algorithms.} {Which is why, one scheduler backend (such as the UserProcessScheduler) takes care of user process scheduling and fairness.} - -\section{References} - -\begin{enumerate} - \item CoreProcessScheduler.h (2025), \href{https://github.com/nekernel-org/nekernel/blob/develop/src/kernel/KernelKit/CoreProcessScheduler.h}{github.com} - - \item NeKernel.org (2025), \href{https://nekernel.org/nekernel}{nekernel.org} - \item Scheduling: Introduction (2012), \href{https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched.pdf}{pages.cs.wisc.edu} - - \item Processor Affinity, Multiple CPU Scheduling (2003), \href{https://www.tmurgent.com/WhitePapers/ProcessorAffinity.pdf}{tmurgent.com} - - \item El Mahrouss, A. (2026). Methodology for Freestanding Development.\\ Zenodo. https://doi.org/10.5281/zenodo.18362425 - - \item El Mahrouss, A. (2026). The Execution Semantics: On Axioms, Domains, and Authority. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362375 -\end{enumerate} - -\end{document} \ No newline at end of file diff --git a/source/wg03/paper.tex b/source/wg03/paper.tex new file mode 100644 index 0000000..34ac08c --- /dev/null +++ b/source/wg03/paper.tex @@ -0,0 +1,98 @@ +% AUTHOR: Amlal El Mahrouss +% PURPOSE: WG03: The Nectar Programming Language. + +\documentclass[11pt, a4paper]{article} +\usepackage{graphicx} +\usepackage{listings} +\usepackage{xcolor} +\usepackage{hyperref} +\usepackage[margin=0.5in,top=1in,bottom=1in]{geometry} + +\title{Design of the Nectar Programming Language.} +\author{Amlal El Mahrouss\\\texttt{amlal@nekernel.org}} +\date{January 2026} + +\definecolor{codegray}{gray}{0.95} +\definecolor{codeblue}{rgb}{0.1,0.1,0.8} +\definecolor{codegreen}{rgb}{0,0.6,0} +\definecolor{codepurple}{rgb}{0.58,0,0.82} + +\lstset{ + language=C++, + backgroundcolor=\color{codegray}, + basicstyle=\footnotesize\ttfamily, + keywordstyle=\color{codeblue}\bfseries, + commentstyle=\color{codegreen}, + stringstyle=\color{codepurple}, + numbers=left, + numberstyle=\tiny\color{gray}, + stepnumber=1, + numbersep=5pt, + breaklines=true, + breakatwhitespace=false, + frame=single, + rulecolor=\color{black}, + captionpos=b, + keepspaces=true, + showspaces=false, + showstringspaces=false, + showtabs=false, + tabsize=2 +} + +\begin{document} + +\bf \maketitle + +\begin{center} + \rule[0.01cm]{17cm}{0.01cm} +\end{center} + +\abstract +{ + Nectar as presented in its primer is a systems compiled programming language—designed for low-level systems programming with high-level abstractions. + It is statically typed—compiled, and supports programming paradigms such as generic programming—and procedural programming. +} + +\begin{center} + \rule[1cm]{17cm}{0.01cm} +\end{center} + +\section{The 'Hello World' Program.} + +Let a program $P$ be: + +\begin{lstlisting} +extern printf; + +const main() +{ + const written := printf("%s:13", "Hello, world!\n"); + return written; +} +\end{lstlisting} $P$ shall execute: + +\begin{lstlisting} +$ Hello, world! +\end{lstlisting} And return variant $written$, now defined as $W$, upon completion. Such program that we denote as $\Theta$ may be defined as: + +\begin{equation} + \Theta(x) = \lambda x.(P(x)) +\end{equation} Where $P(x)$ is $P$ with an argument of $x$. \\ Let $\Theta(x)$ be defined as the $\lambda$-Execution of a program $P$. +\section{References} + +\begin{enumerate} + \item NeKernel.org (2026), \href{https://nekernel.org/nekernel}{https://nekernel.org} + \item NeKernel.org Primer (2026), \href{https://nekernel.org/nectar\_primer.html}{https://nekernel.org/nectar\_primer.html} + \item El Mahrouss, A. (2026). The Execution Semantics: On Axioms, Domains, and Authority. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362375 + \item El Mahrouss, A. (2026). The Mathematics of Execution. Zenodo. \\https://doi.org/10.5281/zenodo.18399140 + \item Church, A. (1936). An Unsolvable Problem of Elementary Number Theory. American Journal of Mathematics, 58(2), 345–363. https://doi.org/10.2307/2371045 +\end{enumerate} + +\section{Definitions} + + \item Nectar: A compiled systems programming language—currently studied in this paper. + \item $\lambda$-Execution: Formally defined as: $\Theta(x) = \lambda x.(P(x))$. + \item $W$: The return variant—an $\lambda$-Execution variable based on the $\lambda$-Execution result. + +\end{document} diff --git a/source/wg03/wg03.tex b/source/wg03/wg03.tex deleted file mode 100644 index 34ac08c..0000000 --- a/source/wg03/wg03.tex +++ /dev/null @@ -1,98 +0,0 @@ -% AUTHOR: Amlal El Mahrouss -% PURPOSE: WG03: The Nectar Programming Language. - -\documentclass[11pt, a4paper]{article} -\usepackage{graphicx} -\usepackage{listings} -\usepackage{xcolor} -\usepackage{hyperref} -\usepackage[margin=0.5in,top=1in,bottom=1in]{geometry} - -\title{Design of the Nectar Programming Language.} -\author{Amlal El Mahrouss\\\texttt{amlal@nekernel.org}} -\date{January 2026} - -\definecolor{codegray}{gray}{0.95} -\definecolor{codeblue}{rgb}{0.1,0.1,0.8} -\definecolor{codegreen}{rgb}{0,0.6,0} -\definecolor{codepurple}{rgb}{0.58,0,0.82} - -\lstset{ - language=C++, - backgroundcolor=\color{codegray}, - basicstyle=\footnotesize\ttfamily, - keywordstyle=\color{codeblue}\bfseries, - commentstyle=\color{codegreen}, - stringstyle=\color{codepurple}, - numbers=left, - numberstyle=\tiny\color{gray}, - stepnumber=1, - numbersep=5pt, - breaklines=true, - breakatwhitespace=false, - frame=single, - rulecolor=\color{black}, - captionpos=b, - keepspaces=true, - showspaces=false, - showstringspaces=false, - showtabs=false, - tabsize=2 -} - -\begin{document} - -\bf \maketitle - -\begin{center} - \rule[0.01cm]{17cm}{0.01cm} -\end{center} - -\abstract -{ - Nectar as presented in its primer is a systems compiled programming language—designed for low-level systems programming with high-level abstractions. - It is statically typed—compiled, and supports programming paradigms such as generic programming—and procedural programming. -} - -\begin{center} - \rule[1cm]{17cm}{0.01cm} -\end{center} - -\section{The 'Hello World' Program.} - -Let a program $P$ be: - -\begin{lstlisting} -extern printf; - -const main() -{ - const written := printf("%s:13", "Hello, world!\n"); - return written; -} -\end{lstlisting} $P$ shall execute: - -\begin{lstlisting} -$ Hello, world! -\end{lstlisting} And return variant $written$, now defined as $W$, upon completion. Such program that we denote as $\Theta$ may be defined as: - -\begin{equation} - \Theta(x) = \lambda x.(P(x)) -\end{equation} Where $P(x)$ is $P$ with an argument of $x$. \\ Let $\Theta(x)$ be defined as the $\lambda$-Execution of a program $P$. -\section{References} - -\begin{enumerate} - \item NeKernel.org (2026), \href{https://nekernel.org/nekernel}{https://nekernel.org} - \item NeKernel.org Primer (2026), \href{https://nekernel.org/nectar\_primer.html}{https://nekernel.org/nectar\_primer.html} - \item El Mahrouss, A. (2026). The Execution Semantics: On Axioms, Domains, and Authority. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362375 - \item El Mahrouss, A. (2026). The Mathematics of Execution. Zenodo. \\https://doi.org/10.5281/zenodo.18399140 - \item Church, A. (1936). An Unsolvable Problem of Elementary Number Theory. American Journal of Mathematics, 58(2), 345–363. https://doi.org/10.2307/2371045 -\end{enumerate} - -\section{Definitions} - - \item Nectar: A compiled systems programming language—currently studied in this paper. - \item $\lambda$-Execution: Formally defined as: $\Theta(x) = \lambda x.(P(x))$. - \item $W$: The return variant—an $\lambda$-Execution variable based on the $\lambda$-Execution result. - -\end{document} diff --git a/source/wg05/paper.tex b/source/wg05/paper.tex new file mode 100644 index 0000000..da2fa29 --- /dev/null +++ b/source/wg05/paper.tex @@ -0,0 +1,106 @@ +% AUTHOR: Amlal El Mahrouss +% PURPOSE: WG05: The Execution Semantics: On Axioms, Domains, and Authority. + +\documentclass[11pt,a4paper]{article} + +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} +\usepackage{amsmath,amssymb,amsthm} +\usepackage{hyperref} +\usepackage[margin=1in]{geometry} + +\title{The Execution Semantics: On Axioms, Domains, and Authority.} +\author{Amlal El Mahrouss\\ +\texttt{amlal@nekernel.org}} +\date{January 2026} + +\begin{document} + +\bf \maketitle + +\begin{center} + \rule[0.01cm]{17cm}{0.01cm} +\end{center} + +\begin{abstract} +This paper presents a foundational framework for execution semantics, consisting of three interconnected theories: the General Harvard Separation Axiom, Execution Domains Theory, and Execution Authority Theory. Together, these establish execution as a primitive concept that cannot be derived from computational models, define boundaries for execution semantics and resource visibility, and formalize the authority governing execution contexts. +\end{abstract} + +\begin{center} + \rule[1cm]{17cm}{0.01cm} +\end{center} + +\section{The General Harvard Separation Axiom} + +Let $G$ be a theory that formally defines execution semantics (domains, contexts, authority). Let $O$ be any theory of computational behavior. + +\subsection{Properties} + +\begin{itemize} + \item If $O$ models computation, then $O$ requires execution to occur. + \item Therefore $O$ implicitly depends on $G$'s primitives (execution must be defined for computation to be theorized). + \item $G$ does not depend on $O$ (execution semantics are primitive, not derived from computational models). +\end{itemize} + +\subsection{Conclusion} + +We cannot derive $G$ from $O$ without circularity: +\begin{itemize} + \item Deriving execution semantics from $O$ would mean ``execution depends on a theory that assumes execution exists.'' + \item This creates an impossible circular dependency. + \item Therefore $G$ must be \textbf{axiomatic}—a foundational primitive that cannot be reduced to other computational theories. +\end{itemize} + +Any attempt to make $G = O$ or $G \subseteq O$ fails because $O$ already assumes $G$'s primitives exist. + +\section{Execution Domains Theory} + +\subsection{Abstract} + +An execution domain defines a boundary for execution semantics, resource visibility, and control flow. + +Let $C$ denote an execution domain in an execution context $E$. Let $D$ be of the same type as $C$ but of a different execution context. + +\subsection{Properties} + +\begin{itemize} + \item $C$ shall not be equal to $D$, as $C$ has a different execution context than $D$. + \item $C$ may be composed of sub-programs within the execution context $E$. +\end{itemize} + +\subsection{On Execution Contexts} + +Execution contexts are treated as abstract semantic parameters, and execution domains as abstract structures indexed by those parameters. + +\section{Execution Authority Theory} + +\subsection{Abstract} + +An execution domain is defined as previously stated in Section~2. An execution authority is responsible for defining whose semantics may be used for an execution context. + +A \emph{trait} is a set of formal rules defining the semantic concepts of an execution context. + +Let $A$ be an execution authority of type $T$, where $T$ is a trait of an execution context. + +\subsection{Properties} + +Let $C$ denote an execution domain in an execution context $E$. Let $Z$ denote an execution domain in an execution context $X$. + +\begin{itemize} + \item If $X$ does not equal or is not semantically substitutable with $E$—or vice versa—then $C$ shall not equal $Z$. + \item If $Z$ or $C$ are defined as a null execution context, then the said context—defined as $N$—is not equal to $\lnot N$. +\end{itemize} + +\section{Conclusion} + +Let $G$ be a theory that formally defines execution semantics—consisting of three foundational theories—the General Harvard Separation Axiom, Execution Domains Theory, and Execution Authority Theory. Together they establish $G$ as a framework that consists of the analysis of Execution Semantics. Or Execution Theory. + +\section{References} + +\begin{itemize} + \item El Mahrouss, A. (2026). Methodology for Freestanding Development. Zenodo. https://doi.org/10.5281/zenodo.18362425 + + \item El Mahrouss, A. (2026). Methodology for Process and Image Computation. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362503 +\end{itemize} + +\end{document} diff --git a/source/wg05/tn/tn001.05.tex b/source/wg05/tn/tn001.05.tex deleted file mode 100644 index 176f22a..0000000 --- a/source/wg05/tn/tn001.05.tex +++ /dev/null @@ -1,79 +0,0 @@ -% AUTHOR: Amlal El Mahrouss -% PURPOSE: WG05.TN001: The Mathematics of Execution. - -\documentclass[11pt,a4paper]{article} - -\usepackage[utf8]{inputenc} -\usepackage[T1]{fontenc} -\usepackage{amsmath,amssymb,amsthm} -\usepackage{hyperref} -\usepackage[margin=1in]{geometry} - -\title{The Mathematics of Execution.} -\author{Amlal El Mahrouss\\ -\texttt{amlal@nekernel.org}} -\date{January 2026} - -\begin{document} - -\bf \maketitle - -\begin{center} - \rule[0.01cm]{17cm}{0.01cm} -\end{center} - -\begin{center} -\begin{abstract} -This paper covers the algebraic properties and concepts of `The Execution Semantics' paper by El Mahrouss, A (2026). It is intended as an additional resource over the aforementioned paper. -We will define their concepts alongside their properties. We assume the reader has read the previous paper on 'The Execution Semantics' by El Mahrouss, A. -\end{abstract} -\end{center} - -\begin{center} - \rule[1cm]{17cm}{0.01cm} -\end{center} - -\section{The Execution Product} - -Let $\Gamma(x, y, z)$ be an execution product of variable arguments $x$, $y$, $z$ defined in compatible and composable execution context $E$: \\ -Let the index $\alpha$ denote the current execution domain of an execution product. -\\ Let the following formula: -\begin{equation} -\Gamma(x, y, z) = \prod_{\alpha=1}^{n}(x_{\alpha} \times y_{\alpha} \times z_{\alpha})+C -\end{equation} - Be defined as the execution product. Where $C$ is the Unknown Execution of $\Gamma(x, y, z)$—now defined as $g(E)$. - -\subsection{Properties} - -\begin{enumerate} - - \item $\Gamma$ as defined previously as the `execution product' shall always be valid within the execution context $E$. - \item The execution context $E$ shall not denote $\varnothing$. - -\end{enumerate} - -\section{The Unknown Execution} - -Let an `Unknown Execution' $U$ be defined regarding an execution product $\Gamma$. \\ -Let $N$ be defined as $\varnothing$. - -\subsection{Properties} - -\begin{enumerate} - - \item $U$ shall not be equal to $N$. - \item The execution domain of $\Gamma$ shall not be $N$. - -\end{enumerate} - -\section{Conclusion} - -Such properties are essential to define `Execution Theory''s as a mathematical construct as per defined in El Mahrouss, A.' paper. - -\section{References} - -\begin{enumerate} - \item El Mahrouss, A. (2026). The Execution Semantics: On Axioms, Domains, and Authority. (v2.0.0). Zenodo. https://doi.org/10.5281/zenodo.18366611 -\end{enumerate} - -\end{document} diff --git a/source/wg05/tn001.05/paper.tex b/source/wg05/tn001.05/paper.tex new file mode 100644 index 0000000..176f22a --- /dev/null +++ b/source/wg05/tn001.05/paper.tex @@ -0,0 +1,79 @@ +% AUTHOR: Amlal El Mahrouss +% PURPOSE: WG05.TN001: The Mathematics of Execution. + +\documentclass[11pt,a4paper]{article} + +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} +\usepackage{amsmath,amssymb,amsthm} +\usepackage{hyperref} +\usepackage[margin=1in]{geometry} + +\title{The Mathematics of Execution.} +\author{Amlal El Mahrouss\\ +\texttt{amlal@nekernel.org}} +\date{January 2026} + +\begin{document} + +\bf \maketitle + +\begin{center} + \rule[0.01cm]{17cm}{0.01cm} +\end{center} + +\begin{center} +\begin{abstract} +This paper covers the algebraic properties and concepts of `The Execution Semantics' paper by El Mahrouss, A (2026). It is intended as an additional resource over the aforementioned paper. +We will define their concepts alongside their properties. We assume the reader has read the previous paper on 'The Execution Semantics' by El Mahrouss, A. +\end{abstract} +\end{center} + +\begin{center} + \rule[1cm]{17cm}{0.01cm} +\end{center} + +\section{The Execution Product} + +Let $\Gamma(x, y, z)$ be an execution product of variable arguments $x$, $y$, $z$ defined in compatible and composable execution context $E$: \\ +Let the index $\alpha$ denote the current execution domain of an execution product. +\\ Let the following formula: +\begin{equation} +\Gamma(x, y, z) = \prod_{\alpha=1}^{n}(x_{\alpha} \times y_{\alpha} \times z_{\alpha})+C +\end{equation} + Be defined as the execution product. Where $C$ is the Unknown Execution of $\Gamma(x, y, z)$—now defined as $g(E)$. + +\subsection{Properties} + +\begin{enumerate} + + \item $\Gamma$ as defined previously as the `execution product' shall always be valid within the execution context $E$. + \item The execution context $E$ shall not denote $\varnothing$. + +\end{enumerate} + +\section{The Unknown Execution} + +Let an `Unknown Execution' $U$ be defined regarding an execution product $\Gamma$. \\ +Let $N$ be defined as $\varnothing$. + +\subsection{Properties} + +\begin{enumerate} + + \item $U$ shall not be equal to $N$. + \item The execution domain of $\Gamma$ shall not be $N$. + +\end{enumerate} + +\section{Conclusion} + +Such properties are essential to define `Execution Theory''s as a mathematical construct as per defined in El Mahrouss, A.' paper. + +\section{References} + +\begin{enumerate} + \item El Mahrouss, A. (2026). The Execution Semantics: On Axioms, Domains, and Authority. (v2.0.0). Zenodo. https://doi.org/10.5281/zenodo.18366611 +\end{enumerate} + +\end{document} diff --git a/source/wg05/wg05.tex b/source/wg05/wg05.tex deleted file mode 100644 index da2fa29..0000000 --- a/source/wg05/wg05.tex +++ /dev/null @@ -1,106 +0,0 @@ -% AUTHOR: Amlal El Mahrouss -% PURPOSE: WG05: The Execution Semantics: On Axioms, Domains, and Authority. - -\documentclass[11pt,a4paper]{article} - -\usepackage[utf8]{inputenc} -\usepackage[T1]{fontenc} -\usepackage{amsmath,amssymb,amsthm} -\usepackage{hyperref} -\usepackage[margin=1in]{geometry} - -\title{The Execution Semantics: On Axioms, Domains, and Authority.} -\author{Amlal El Mahrouss\\ -\texttt{amlal@nekernel.org}} -\date{January 2026} - -\begin{document} - -\bf \maketitle - -\begin{center} - \rule[0.01cm]{17cm}{0.01cm} -\end{center} - -\begin{abstract} -This paper presents a foundational framework for execution semantics, consisting of three interconnected theories: the General Harvard Separation Axiom, Execution Domains Theory, and Execution Authority Theory. Together, these establish execution as a primitive concept that cannot be derived from computational models, define boundaries for execution semantics and resource visibility, and formalize the authority governing execution contexts. -\end{abstract} - -\begin{center} - \rule[1cm]{17cm}{0.01cm} -\end{center} - -\section{The General Harvard Separation Axiom} - -Let $G$ be a theory that formally defines execution semantics (domains, contexts, authority). Let $O$ be any theory of computational behavior. - -\subsection{Properties} - -\begin{itemize} - \item If $O$ models computation, then $O$ requires execution to occur. - \item Therefore $O$ implicitly depends on $G$'s primitives (execution must be defined for computation to be theorized). - \item $G$ does not depend on $O$ (execution semantics are primitive, not derived from computational models). -\end{itemize} - -\subsection{Conclusion} - -We cannot derive $G$ from $O$ without circularity: -\begin{itemize} - \item Deriving execution semantics from $O$ would mean ``execution depends on a theory that assumes execution exists.'' - \item This creates an impossible circular dependency. - \item Therefore $G$ must be \textbf{axiomatic}—a foundational primitive that cannot be reduced to other computational theories. -\end{itemize} - -Any attempt to make $G = O$ or $G \subseteq O$ fails because $O$ already assumes $G$'s primitives exist. - -\section{Execution Domains Theory} - -\subsection{Abstract} - -An execution domain defines a boundary for execution semantics, resource visibility, and control flow. - -Let $C$ denote an execution domain in an execution context $E$. Let $D$ be of the same type as $C$ but of a different execution context. - -\subsection{Properties} - -\begin{itemize} - \item $C$ shall not be equal to $D$, as $C$ has a different execution context than $D$. - \item $C$ may be composed of sub-programs within the execution context $E$. -\end{itemize} - -\subsection{On Execution Contexts} - -Execution contexts are treated as abstract semantic parameters, and execution domains as abstract structures indexed by those parameters. - -\section{Execution Authority Theory} - -\subsection{Abstract} - -An execution domain is defined as previously stated in Section~2. An execution authority is responsible for defining whose semantics may be used for an execution context. - -A \emph{trait} is a set of formal rules defining the semantic concepts of an execution context. - -Let $A$ be an execution authority of type $T$, where $T$ is a trait of an execution context. - -\subsection{Properties} - -Let $C$ denote an execution domain in an execution context $E$. Let $Z$ denote an execution domain in an execution context $X$. - -\begin{itemize} - \item If $X$ does not equal or is not semantically substitutable with $E$—or vice versa—then $C$ shall not equal $Z$. - \item If $Z$ or $C$ are defined as a null execution context, then the said context—defined as $N$—is not equal to $\lnot N$. -\end{itemize} - -\section{Conclusion} - -Let $G$ be a theory that formally defines execution semantics—consisting of three foundational theories—the General Harvard Separation Axiom, Execution Domains Theory, and Execution Authority Theory. Together they establish $G$ as a framework that consists of the analysis of Execution Semantics. Or Execution Theory. - -\section{References} - -\begin{itemize} - \item El Mahrouss, A. (2026). Methodology for Freestanding Development. Zenodo. https://doi.org/10.5281/zenodo.18362425 - - \item El Mahrouss, A. (2026). Methodology for Process and Image Computation. (v1.0.0). Zenodo. https://doi.org/10.5281/zenodo.18362503 -\end{itemize} - -\end{document} diff --git a/tools/addentry.ml b/tools/addentry.ml index 29dce37..79dd687 100644 --- a/tools/addentry.ml +++ b/tools/addentry.ml @@ -1,5 +1,5 @@ (* - File: addrule.ml + File: addentry.ml Purpose: Creates a makefile rule. Copyright 2026, Amlal El Mahrouss & NeKernel.org Authors. Licensed under Apache 2.0. @@ -9,8 +9,32 @@ open Stdlib open Out_channel open Printf -(* - We just make a LaTeX file with the given title. -*) -let () = if Array.length Sys.argv >= 3 then - printf "We are done here."; +let paper_name_index : int = 2 +let file_index : int = 1 + +let format = format_of_string + " + +PDFTEX ?= pdflatex +HTMLTEX ?= htlatex + +.PHONY: %s +%s: + $(HTMLTEX) source/%s/paper.tex + $(PDFTEX) source/%s/paper.tex +" +;; + +let () = + if Array.length Sys.argv >= 3 then + let out_file = Sys.argv.(file_index) ^ ".mk" in + let file = open_text out_file in + let name = Sys.argv.(paper_name_index) in + + fprintf file format name name name name; + + close_out file + else ( + printf "addentry: Add paper Makefile entry.\n"; + printf "addentry: usage: \n" + ) \ No newline at end of file diff --git a/tools/addpaper.ml b/tools/addpaper.ml index ec91c58..e6cca9b 100644 --- a/tools/addpaper.ml +++ b/tools/addpaper.ml @@ -9,6 +9,7 @@ open Stdlib open Out_channel open Printf +let email_index : int = 4 let author_index : int = 3 let title_index : int = 2 let file_index : int = 1 @@ -21,7 +22,7 @@ let format = format_of_string " \\usepackage[margin=0.5in,top=1in,bottom=1in]{geometry} \\title{%s} -\\author{%s.\\\\john@nekernel.org} +\\author{%s.\\\\%s} \\date{\\today} \\begin{document} @@ -40,13 +41,14 @@ let format = format_of_string " (* We just make a LaTeX file with the given title. *) -let () = if Array.length Sys.argv >= 4 then +let () = if Array.length Sys.argv >= 5 then let out_file : string = Sys.argv.(file_index)^".tex" in let file : out_channel = open_text out_file in fprintf file format Sys.argv.(title_index); fprintf file format Sys.argv.(author_index); + fprintf file format Sys.argv.(email_index); close_out file; else ( - printf "addpaper: Creates LaTeX papers.\n"; + printf "addpaper: Creates papers for TeX.\n"; printf "addpaper: usage: \n" ); diff --git a/wg01.mk b/wg01.mk new file mode 100644 index 0000000..d93f7ef --- /dev/null +++ b/wg01.mk @@ -0,0 +1,11 @@ +# File: wg01.tex +# Author: Amlal El Mahrouss +# Purpose: Generate HTML and PDF papers from LaTex documents. +# (C) 2025-2026 Amlal El Mahrouss. +# Licensed under Apache 2.0. + +.PHONY: wg01 +wg01: + $(HTMLTEX) source/wg01/paper.tex + $(PDFTEX) source/wg01/paper.tex + diff --git a/wg02.mk b/wg02.mk new file mode 100644 index 0000000..e12bab3 --- /dev/null +++ b/wg02.mk @@ -0,0 +1,11 @@ +# File: wg02.tex +# Author: Amlal El Mahrouss +# Purpose: Generate HTML and PDF papers from LaTex documents. +# (C) 2025-2026 Amlal El Mahrouss. +# Licensed under Apache 2.0. + +.PHONY: wg02 +wg02: + $(HTMLTEX) source/wg02/paper.tex + $(PDFTEX) source/wg02/paper.tex + diff --git a/wg03.mk b/wg03.mk new file mode 100644 index 0000000..896d9bb --- /dev/null +++ b/wg03.mk @@ -0,0 +1,11 @@ +# File: wg03.tex +# Author: Amlal El Mahrouss +# Purpose: Generate HTML and PDF papers from LaTex documents. +# (C) 2025-2026 Amlal El Mahrouss. +# Licensed under Apache 2.0. + +.PHONY: wg03 +wg03: + $(HTMLTEX) source/wg03/paper.tex + $(PDFTEX) source/wg03/paper.tex + -- cgit v1.2.3