## Assembly Sorting CLI Tool for Linux (x86_64)
The purpose of this project is to design and implement
a command-line sorting utility in **x86_64/Linux assembly**,
demonstrating performance optimization, software engineering best practices,
and professional deployment workflows.

---

## Todo
- [ ] Command-line arguments parser
    - [ ] Handlers
        - [ ] Reverse handler
        - [ ] Output handler
        - [x] Version handler
        - [ ] Help handler
        - [ ] Default handler
    - [ ] 'strcmp' function

 - [ ] **Discuss exit codes**

 - [ ] **CI / GitLab Pipelines**
    > [!NOTE]
    > Automatic build, test, benchmark, and packaging using `.gitlab-ci.yaml`
    > See [Getting Started Guide](https://gitlab-docs-d6a9bb.gitlab.io/ee/ci/) for **GitLab CI**.

 - [ ] **Benchmarking**
    > [!NOTE]
    > Possibly via a shell script.
    > Use `time` to measure execution time.
    > Run benchmarks on different dataset:
    > small, medium, large, numbers, letters, dates[?]

 - [ ] **Documentation**
    - [ ] **Usage Message**
    - [ ] **Man Page**
    - [ ] **Bash Completion**

 - [ ] **Packaging / Deployment**
    > [!NOTE]
    > Build distributable tarballs (`.tar.gz`)
    > Arch Linux package (`makepkg`)

---

## Scope
### Product Specification
 - Providep a **CLI sorting tool** capble of reading from files and stdin.
 - Support **multiple sorting modes** via flags:
    - Ascending (default)
    - Descending (`-r` or `--reverse`)
    - Numeric
 
 - Implement in **x86_64 Linux assembly**.
 - Include automated **CI/CD testing, benchmarking and packaging**

 ---

## Doc
### Function / Procedure Header Docstring
```asm
# --------------------------------------------
# FUNCTION: my_function
# PURPOSE : Adds two integers
# INPUTS  : eax = first integer
#           ebx = second integer
# OUTPUTS : eax = sum
# CLOBBERS: none
# NOTES   : Preserves all registers except eax
# --------------------------------------------
```

---

## Git setup
### Commit messages
```git
<type>(<scope>): <short summary>

# Summary should be concise (max 72 chars), written in present tense.
# Keep it clear and descriptive — what is changing and why?

# --------------------------------------------------------
# Optional body:
# Use this section to explain the change in more detail.
# Focus on the *what* and *why*, not the *how* unless needed.
# Wrap lines at 72 characters.
# --------------------------------------------------------

# Optional footer:
# - Mention related issues or PRs (Closes #123, etc.)
# - Use BREAKING CHANGE: for breaking changes

# --------------------------------------------------------
# Valid <type> values:
#
# feat      - A new feature
# fix       - A bug fix
# docs      - Documentation changes only
# style     - Code style changes (formatting, missing semi-colons, etc.)
# refactor  - Code changes that neither fix a bug nor add a feature
# perf      - Performance improvements
# test      - Adding or updating tests
# chore     - Changes to build process, tooling, or other non-code tasks
# ci        - Changes to CI configuration or scripts
# build     - Changes that affect the build system or external dependencies
# --------------------------------------------------------
```

---