vov

List all options, with brief explanations.

Run in interactive mode; this option will be ignored if you specify a program_file in the command line. When -i is in effect, vov starts with a bootstrap program that read opcodes from the input device (usually your keyboard), store them in RAM and, when you type the halt instruction, run your code.

The bootstrap program is located at the end of the machine's RAM, therefore it don't ask you the starting offset where to place your code (it assumes 0), and you are free to write your code without count the "offset slide" (i.e. when jump). The bootstrap code uses 13 words of memory; it's possible to make it more small without insert a "want to survive" feature that don't allow you to overwrite the bootstrap code (when -i is in effect you don't have all RAM available).

Limit the maximum memory used by vov to size bytes. If you don't set this option explicitly the default value will be used (2000000 bytes). This option may have no effects on your system.

Run in quiet mode; do not print the introductory and copyright messages. These messages are also suppressed in batch mode.

Limit the maximum cpu time used by vov to secs seconds. If you don't set this option explicitly the default value will be used (2 seconds). This option may have no effects on your system.

Run in verbose mode; this will print lots of useful information on the output device saying what the machine is actually doing; useful for debugging purposes.

Print version information and then exit.

• Slackware 8.1

• Slackware 10.2

• Slackware 11.0

• KUbuntu 5.10 (breezy)

• KUbuntu 6.06 (dapper)

• Ubuntu 6.10 (edgy)

• FreeBSD 6.0-RELEASE

• NetBSD 2.1

• OpenBSD 3.8

• MS-DOS Version 3.30 (DJGPP)

• MS-DOS Version 5.00 (DJGPP)

• MS-DOS Version 6.00 (DJGPP)

• MS-DOS Version 6.20 (DJGPP)

• MS-DOS Version 6.22 (DJGPP)

• FreeCom version 0.82 pl 3 XMS_Swap [Dec 10 2003 06:49:21] (DJGPP)

• Microsoft Windows 98 (MSVC for Win32)

• Microsoft Windows XP (MSVC for Win32 - DJGPP)

• Microsoft Windows Vista (MSVC for Win32 - DJGPP)

• This is the general flow control in a vov session:

  read-stdin --- parse-statement --- add-opcode --- boot --- run --- halt / | read-script _/ interactive-mode

  When vov reads a script from a file (stdin is a file) each statement is parsed; if there is any parser error, vov will die immediately, otherwise the given opcode is set on the specified offset. These simple steps are executed for each statement in your script until the end of file is reached. At this point the RAM is set and the machine can boot executing your program until the halt instruction is reached or an error occurred.

  Using the interactive mode we don't need to parse at all; the bootstrap program is automatically loaded in the RAM and the machine can boot executing it. The bootstrap program read your program instructions (numeric encoded) from stdin and place them in RAM starting from offset 0 until the halt instruction is read. At this point the bootstrap program do a jump to the offset 0 and starts execute your program until the halt instruction is reached or an error occurred. See the -i option for more details.

• The cheapest and easiest way to implement the RAM of the Von-Neumann machine is a flat static array (looking at the definition) of thousands (signed) integers. If you also want to implement a little sanity check to keep track of untouched RAM words (i.e. just a flag set to 1 when we write on a word therefore we will no read from uninitialized memory) then the cheapest and easiest way to implement the machine RAM become a flat static array of thousands structures containing two integers. We could declare the flag for untouched RAM words as char or as bit-field but if we want to write a portable code we can't use some gcc(1)-ism like __attribute__((packed)); therefore the size of a single structure is always the same due to padding bytes (8 bytes on my system using gcc(1)). The resulting machine RAM (8000 bytes on my system using gcc(1)) is, then, all allocated on the program's stack; even if you don't care that this can cause problems on some (old/embedded) systems, you should note that this waste a lot of memory because an average vov program don't use more than 50 RAM words. On the average case, then, the flat array waste a lot of memory even if it is fast (the access time do not depends on the RAM size but it takes O(1) time in all cases).

  For this reason, vov implements the Von-Neumann machine RAM with a dynamic-allocated structure. One easy and fast data structure we can implement is an AVL tree (only lookup and insertion) ordered by RAM offsets containing a 32-bit signed integer (the opcode). Now the access time depends on the RAM size but it takes O(log N) time in both the average and worst cases; since vov only have 1000 RAM words on the worst case this should be fast enough.

  Using this implementation we automatically have the little sanity check as described before: if, during a memory read, the lookup function do not find the requested node then we are trying to access an uninitialized memory word. This is "for free" without the need of any extra flag. During a store operation if the lookup function do not find the requested node (offset) then we simply need to add it to the RAM (add a node to the AVL tree) or, if the lookup function found it, simply update the opcode. That's should be easy enough.

  Thus all required memory goes into the heap instead of the program's stack therefore should be no problem even in some (old/embedded) systems. All sounds good but there is another problem: one malloc(3) for each RAM word (one tree node) is, in general, slow.

  We could use a big buffer (from now called hunk) and play with pointers arithmetic allocating memory only the first time we need it, then keep feeding the hunk until there is no more bytes left on it (or the requested size do not fit). At this point we could realloc(3) the hunk (doubling the size) and go ahead but the realloc(3) man page says that it returns a pointer to the newly allocated memory, [...] and may be different from ptr.

  For this reason we can't use realloc(3) to extend our hunk size or we may risk to lost all our pointers to already allocated tree nodes.

  vov uses a FIFO linked list of hunks and when one hunk is full (or the requested size do not fit) it allocates a new one, instead of realloc(3)-ing the old one. This ensure that no pointers will be lost. To minimize the overhead, the hunks list is a double-linked FIFO list with two pointers: one to the first and one to the last hunk: therefore, when we need to insert a new hunk (on the end of the queue), we don't need to scan the entire list. Thus, to keep minimizing the malloc(3)s, vov allocates memory only one time per hunk using the first bytes to hold the hunk structure (a list cell) and the left bytes as free space available for the tree nodes (RAM words) instead of allocating the list cell and then the hunk: it should be faster, and less memory should be wasted in rounding up chunk sizes (as many implementations do). This also ensure only one malloc(3) per hunk where all required bytes are in a sequence of consecutive addresses in the virtual address space therefore it should not waste space because it maintains memory in ways that minimize fragmentation (holes in contiguous chunks of memory that are not used by the program) and this also helps minimize page and cache misses during program execution because chunks of memory that are typically used together are allocated near each other.

  vov, internally, uses malloc(3) only for the RAM words (tree nodes), therefore things are simple: since the nodes are homogeneous data (same size) if a hunk doesn't fit for an allocation then doesn't fit even for the next one. Therefore when we need to allocate a new RAM word (tree node) we don't need (again) to scan the entire list but we can just check the last hunk (we have a pointer to it) for available bytes: that has practically no overhead. We don't need any best-fit, first-fit, et cetera algorithm implementations keeping the code (more fast and) KISS (Keep It Simple, Stupid). This is very important because security holes can't show up in features that don't exist©.

  For all reasons explained before (as minimize page and cache misses during program execution), hunk size is set to the size of system memory page. Size of memory page is architecture and operating system dependent. You can set it using the configure script. By default memory page size is set to 4096 bytes. This should ensure that no memory will be left unused; on my (32-bit) system, where a memory page is 4096 bytes, compiling the code using gcc(1), the size of a list cell is 16 bytes and size of a tree node is 20 bytes therefore one hunk can hold up to 204 memory words filling itself perfectly. On a 64-bit system, where a memory page is 4096 bytes, compiling the code using gcc(1), both the size of a list cell and a tree node are 32 bytes therefore one hunk can hold up to 127 memory words filling itself perfectly. Thus, on all cases, allocating one hunk is enough for almost all vov programs (just one malloc(3) for an average vov session).

• I've mostly given up on the standard C library. Many of its facilities, particularly stdio, seem designed to encourage bugs©; thus premier causes for bloat are stdio and the printf family of functions. Since vov was written even to be small, it don't use any of these functions. vov's input/output routines are stolen (and modified) from libowfat a GPL version of the djb library code. Since I don't want any external and non standard dependencies and I modified the used routines I don't link vov against libowfat directly.

• The parser is realized using flex(1) and bison(1). I made some little changes to the scanner generated by flex(1) because I don't want to use any stdio facilities (as printf, FILE *. et cetera) keeping the code small and not bug-prone (see the Input/Output section). If you have any problem to apply my patch after you regenerated the scanner, please note that I used an old version of flex(1) (2.5.4a) because it works for me and thus more recently versions of flex(1) insert some code (as the function clearerr that accepts a FILE * as parameter) that I can't modify.

  I also rewrote the yy_fatal_error routine because the generated version has some memory and descriptor leaks. The default function do not close the parsed FILE * (descriptor leak) and do not destroy the yy_current_buffer (memory leak).

• vov don't want to eat all your shared resources as memory and cpu time (the only shared resources that vov will actually use). I believe that include separate code in every application to impose configurable artificial limits on every dynamically allocated data is a wrong solution to make a secure program (you can always fail putting an artificial limit on a dynamically allocated data) therefore I use rlimits on systems that support it.

  These limits are only for your convenience; you can't override system defined limits. If an user on a system sets a limit greater than the relative system limit then the system limit will be used.

  If you think that arbitrary memory allocation up to rlimits or physical limits is a bug, please wait a second: systems that allows users to allocate any amount of memory are vulnerable before they are running vov because they aren't well managed systems and can be damaged by memory exhaustion attacks, whether or not they are running vov. Probably, on these systems, vov is the last problem of the system administrator. By the way, on UNIX like systems, we have the rlimits facilities.