Mu programs are lists of functions. Each function has the following form:
```
fn _name_ _inout_ ... -> _output_ ... {
_statement_
_statement_
...
}
```
Each function has a header line, and some number of statements, each on a
separate line. Headers describe inouts and outputs. Inouts can't be registers,
and outputs _must_ be registers. In the above example, the outputs of both
`do-add` and `main` have type `int` and are available in register `ebx` at the
end of the respective calls.
The above program also demonstrates a function call (to the function `do-add`).
Function calls look the same as primitive statements: they can return (multiple)
outputs in registers, and modify inouts passed in by reference. In addition,
there's one more constraint: output registers must match the function header.
For example:
```
fn f -> x/eax: int {
...
}
fn g {
a/eax <- f # ok
a/ebx <- f # wrong; `a` must be in register `eax`
}
```
The function `main` is special; it is where the program starts running. It
must always return a single int in register `ebx` (as the exit status of the
process). It can also optionally accept an array of strings as input (from the
shell command-line). To be precise, `main` must have one of the following
two signatures:
- `fn main -> x/ebx: int`
- `fn main args: (addr array (addr array byte)) -> x/ebx: int`
(The names of the inout and output are flexible.)
Mu encloses multi-word types in parentheses, and types can get quite expressive.
For example, you read `main`'s inout type as "an address to an array of
addresses to arrays of bytes." Since addresses to arrays of bytes are almost
always strings in Mu, you'll quickly learn to mentally shorten this type to
"an address to an array of strings".
## Blocks
Blocks are useful for grouping related statements. They're delimited by `{`
and `}`, both each alone on a line.
Blocks can nest:
```
{
_statements_
{
_more statements_
}
}
```
Blocks can be named (with the name ending in a `:` on the same line as the
`{`):
```
$name: {
_statements_
}
```
Further down we'll see primitive statements for skipping or repeating blocks.
Besides control flow, the other use for blocks is...
## Local variables
Functions can define new variables at any time with the keyword `var`. There
are two variants of the `var` statement, for defining variables in registers
or memory.
```
var name: type
var name/reg: type <- ...
```
Variables on the stack are never initialized. (They're always implicitly
zeroed out.) Variables in registers are always initialized.
Register variables can go in 6 integer registers: `eax`, `ebx`, `ecx`, `edx`,
`esi` and `edi`. Floating-point values can go in 8 other registers: `xmm0`,
`xmm1`, `xmm2`, `xmm3`, `xmm4`, `xmm5`, `xmm6` and `xmm7`.
Defining a variable in a register either clobbers the previous variable (if it
was defined in the same block) or shadows it temporarily (if it was defined in
an outer block).
Variables exist from their definition until the end of their containing block.
Register variables may also die earlier if their register is clobbered by a
new variable.
Variables on the stack can be of many types (but not `byte`). Integer registers
can only contain 32-bit values: `int`, `byte`, `boolean`, `(addr ...)`. Floating-point
registers can only contain values of type `float`.
## Integer primitives
Here is the list of arithmetic primitive operations supported by Mu. The name
`n` indicates a literal integer rather than a variable, and `var/reg` indicates
a variable in a register, though that's not always valid Mu syntax.
```
var/reg <- increment
increment var
var/reg <- decrement
decrement var
var1/reg1 <- add var2/reg2
var/reg <- add var2
add-to var1, var2/reg
var/reg <- add n
add-to var, n
var1/reg1 <- sub var2/reg2
var/reg <- sub var2
sub-from var1, var2/reg
var/reg <- sub n
sub-from var, n
var1/reg1 <- and var2/reg2
var/reg <- and var2
and-with var1, var2/reg
var/reg <- and n
and-with var, n
var1/reg1 <- or var2/reg2
var/reg <- or var2
or-with var1, var2/reg
var/reg <- or n
or-with var, n
var1/reg1 <- xor var2/reg2
var/reg <- xor var2
xor-with var1, var2/reg
var/reg <- xor n
xor-with var, n
var1/reg1 <- negate
negate var
var/reg <- copy var2/reg2
copy-to var1, var2/reg
var/reg <- copy var2
var/reg <- copy n
copy-to var, n
compare var1, var2/reg
compare var1/reg, var2
compare var/eax, n
compare var, n
var/reg <- shift-left n
var/reg <- shift-right n
var/reg <- shift-right-signed n
shift-left var, n
shift-right var, n
shift-right-signed var, n
var/reg <- multiply var2
```
Any statement above that takes a variable in memory can be replaced with a
dereference (`*`) of an address variable (of type `(addr ...)`) in a register.
(Types can have multiple words, and are wrapped in `()` when they do.) But you
can't dereference variables in memory. You have to load them into a register
first.
Excluding dereferences, the above statements must operate on non-address
values with primitive types: `int`, `boolean` or `byte`. (Booleans are really
just `int`s, and Mu assumes any value but `0` is true.) You can copy addresses
to int variables, but not the other way around.
## Floating-point primitives
These instructions may use the floating-point registers `xmm0` ... `xmm7`
(denoted by `/xreg2` or `/xrm32`). They also use integer values on occasion
(`/rm32` and `/r32`). They can't take literal floating-point values.
```
var/xreg <- add var2/xreg2
var/xreg <- add var2
var/xreg <- add *var2/reg2
var/xreg <- subtract var2/xreg2
var/xreg <- subtract var2
var/xreg <- subtract *var2/reg2
var/xreg <- multiply var2/xreg2
var/xreg <- multiply var2
var/xreg <- multiply *var2/reg2
var/xreg <- divide var2/xreg2
var/xreg <- divide var2
var/xreg <- divide *var2/reg2
var/xreg <- reciprocal var2/xreg2
var/xreg <- reciprocal var2
var/xreg <- reciprocal *var2/reg2
var/xreg <- square-root var2/xreg2
var/xreg <- square-root var2
var/xreg <- square-root *var2/reg2
var/xreg <- inverse-square-root var2/xreg2
var/xreg <- inverse-square-root var2
var/xreg <- inverse-square-root *var2/reg2
var/xreg <- min var2/xreg2
var/xreg <- min var2
var/xreg <- min *var2/reg2
var/xreg <- max var2/xreg2
var/xreg <- max var2
var/xreg <- max *var2/reg2
```
Remember, when these instructions use indirect mode, they still use an integer
register. Floating-point registers can't hold addresses.
Two instructions in the above list are approximate. According to the Intel
manual, `reciprocal` and `inverse-square-root` [go off the rails around the
fourth decimal place](x86_approx.md). If you need more precision, use `divide`
separately.
Most instructions operate exclusively on integer or floating-point operands.
The only exceptions are the instructions for converting between integers and
floating-point numbers.
```
var/xreg <- convert var2/reg2
var/xreg <- convert var2
var/xreg <- convert *var2/reg2
var/reg <- convert var2/xreg2
var/reg <- convert var2
var/reg <- convert *var2/reg2
var/reg <- truncate var2/xreg2
var/reg <- truncate var2
var/reg <- truncate *var2/reg2
```
There are no instructions accepting floating-point literals. To obtain integer
literals in floating-point registers, copy them to general-purpose registers
and then convert them to floating-point.
One pattern you may have noticed above is that the floating-point instructions
above always write to registers. The only exceptions are `copy` instructions,
which can write to memory locations.
```
var/xreg <- copy var2/xreg2
copy-to var1, var2/xreg
var/xreg <- copy var2
var/xreg <- copy *var2/reg2
```
Floating-point comparisons always put a register on the left-hand side:
```
compare var1/xreg1, var2/xreg2
compare var1/xreg1, var2
```
## Operating on individual bytes
A special-case is variables of type `byte`. Mu is a 32-bit platform so for the
most part only supports types that are multiples of 32 bits. However, we do
want to support strings in ASCII and UTF-8, which will be arrays of 8-bit
bytes.
Since most x86 instructions implicitly load 32 bits at a time from memory,
variables of type 'byte' are only allowed in registers, not on the stack. Here
are the possible statements for reading bytes to/from memory:
```
var/reg <- copy-byte var2/reg2 # var: byte, var2: byte
var/reg <- copy-byte *var2/reg2 # var: byte, var2: (addr byte)
copy-byte-to *var1/reg1, var2/reg2 # var1: (addr byte), var2: byte
```
In addition, variables of type 'byte' are restricted to (the lowest bytes of)
just 4 registers: `eax`, `ecx`, `edx` and `ebx`. As always, this is due to
constraints of the x86 instruction set.
## Primitive jumps
There are two kinds of jumps, both with many variations: `break` and `loop`.
`break` instructions jump to the end of the containing block. `loop` instructions
jump to the beginning of the containing block.
All jumps can .TH RANGER 1 ranger-1.0.4
.SH NAME
ranger - visual file manager
.\"-----------------------------------------
.SH SYNOPSIS
.B ranger
.R [OPTIONS] [FILE]
.\"-----------------------------------------
.SH DESCRIPTION
ranger is a file manager with an ncurses frontend that is designed for
smooth interaction with the human visual interface and compatibility with
the muscle memory of individuals with long term exposure to common CLI tools
of unix-like operating systems.
.\"-----------------------------------------
.SH OPTIONS
.TP
--version
Print the version and exit.
.TP
-h, --help
Print a list of options and exit.
.TP
-d, --debug
Activate the debug mode: Whenever an error occurs, ranger will exit and
print a full backtrace. The default behaviour is to merely print the
name of the exception in the statusbar/log and to try to keep running.
.TP
-c, --clean
Activate the clean mode: Ranger will not access or create any configuration
files nor will it leave any traces on your system. This is useful when
your configuration is broken, when you want to avoid clutter, etc.
.TP
-r \fIdir\fR, --confdir=\fIdir\fR
Define a different configuration directory. The default is $HOME/.ranger.
.TP
-m \fIn\fR, --mode=\fIn\fR
When a filename is supplied, make it run in mode \fIn\fR. Check the
documentation for more information on modes.
.TP
-f \fIflags\fR, --flags=\fIflags\fR
When a filename is supplied, make it run with the flags \fIflags\fR. Check the
documentat