changelog shortlog tags changeset files revisions annotate raw

bin/Microcosm

changeset 754: d39e613e8266
author: Gregor (codu.org)
date: Mon Jan 03 22:11:26 2011 +0000 (16 months ago)
permissions: -rwxr-xr-x
description: medit/bin/N-in-a-row game chebang=#!/usr/bin/env .wiki cont=This is an idea for a game which:

* Is entirely non-random
* Has no hidden information
* Involves strategy
* Is playable by normal humans
* Has an infinite state-space
* Is hopefully fun
* Is generally unsolvable
** Although it may be solvable when restricted to "reasonable" board sizes

The basic idea is:

* The gameboard is an infinite grid
* One player starts by placing a single X anywhere
* The second player must get two Os in a row within f(1) turns (f to be defined)
* Generally, if you get N in a row, then the opponent has f(N) turns to get N+1 in a row or you win. Then it repeats when they have N+1
* You can also get N+1 in a row yourself, in which case the counter resets with you still in the winning position.

Open questions:

* What is f?
* Can you place your symbol anywhere, or only next to the existing game?

Of course, the most vital part is the definition of f, and we're not yet sure what to do with that.		 
     1#!/usr/bin/env .wiki

     2(Microcosm is not yet implemented, so this description may change)

     3

     4Microcosm is an OS (of sorts) designed to run on top of any other OS. It has its own system call layer, providing a single target ABI for binaries. That system call layer is implemented in terms of lower level (host-specific) system calls, and so must to a certain degree be reimplemented per OS.

     5

     6At its core, Microcosm has only three intrinsic functions: It can load (and run) ELF binaries, manage multiple threads, and handle syscalls. The only syscalls provided by the core are:

     7 * -1: Register syscall

     8 * -2: Get syscall

     9 * -3: Deregister syscall

    10 * -8: Expand thread structure

    11 * -9: Get current thread structure

    12 * -16: Spawn thread

    13 * -17: Initialize thread

    14 * -18: Kill thread

    15 * -19: Join thread (wait)

    16These system calls are clearly divided into three groups.

    17

    18==Syscall registration==

    19The core syscalls -1, -2 and -3 control the registration of system calls. Microcosm allows syscalls to be added at runtime, and these three builtin syscalls allow that:

    20

    21===Register syscall===

    22{{syscall(-1, callnumber, functionptr, 0, 0)}}

    23Syscall -1 registers a system call. The system call 'callnumber' is associated with the function 'functionptr'. The previous value is returned, or NULL if the system call was unassigned. This system call cannot fail non-catastrophically.

    24

    25===Get syscall===

    26{{syscall(-2, callnumber, 0, 0, 0)}}

    27Syscall -2 gets the current association of a system call. The function pointer is returned, or NULL if the system call is unassigned.

    28

    29===Deregister syscall===

    30{{syscall(-2, callnumber, 0, 0, 0)}}

    31Syscall -3 deregisters the given system call. The return value is always 0, and this system call cannot fail non-catastrophically.

    32

    33==Other core system calls==

    34(To be documented later)

    35

    36==Modules==

    37When Microcosm is started, before loading a binary, it loads the ELF file microcosm-modules.so . That ELF shared object file should depend on a number of other modules, which will all be loaded. The initialization code for the modules will generally register system calls, expand the thread data structure, and do any other initialization steps potentially necessary.

    38

    39Usually, these modules will be implemented with an 'in-microcosm' component depending on an 'out-of-microcosm' component. Microcosm's ELF loader allows dependencies on external shared libraries (or DLLs on Windows) by registering dependencies in the guest .so named (e.g.) libhost_libc.so.6 (for libc.so.6 on the host).

    40

    41==FOO==

    42More documentation to come!