Microcontroller Standalone Interactive Operating System (uC-OS)
author Neil Franklin, last modification 2007.11.29

intended for uses in future uC experiment projects
  stand alone fast development and testing direct on the target system
    with more comfort than current external "batch compile and flash" method
    should in the end be even more comfortable than semi-batch unix development
small systems based on standard 8bit uCs such as 8051/AVR/PIC18
  but also usable for on 8/16bit uP sys such as Z80/6502/80188
    original idea of this system on C64 6502, the best of "monitor" programs
      and forth all rolled into one, but other projects got in way
  possibly later also 32bit embedded systems, such as ARM uCs
    or ARM uP sys such as NSLU-2 or MIPS uP such as WLAN router
    or even on Mini-ITX style small x86 PC system
    or even first development x86 in an linux process, linux VM as machine
      but requires overhead ELF file format, linux exec and process layout
        linux kernel syscalls as devices, VT sequences, sockets, resolver, X
      OTOH would allow x86 assmbler teaching on PC, and decent linux software
  preferably an open multi-vendor platform, so 8051 first candidate
    but requires also simple memory model w enough space, so better AVR
    and is simpler to work with code execution from RAM, so better uP or PC
      and allows minimal prevcompiled binary, compile rest on every boot
        possibly option to fetch different sources
compiled code in flash, execute in place, data in SRAM + RAM/EEPROM/flash-disk
  for this possibly an external 8pin SEEPROM or serial flash chip, 4*code size
  for changing stuff in code flash or disk EEPROM/flash use buffers in SRAM
  for uP+flash only boot mirror code into RAM, run from there
    flash contains just bootloader and compressed(?) RAM system
    allows writing to flash for update, as that is not in exec-read usage
memory management by dictionary as in forth
  possibly code+constants in blocks with buddy allocation
    allows replacing one implementation without "forget"-ing everything since
    dictionary separate structure in own buddy, like filesystem directories
      possibly name space management like an hierarchic filesystem
    but recompile should be fast anyway, if stuff in RAM/EEPROM/flash-disk
      so no need for multiple programs in memory at one, no name collisions
code directly compiled "subroutine threaded", no threading interpreter
  data model 8bit registers+returnstack+memory given by processors machine code
    not 16bit datastack+returnstack+memory like forth, no vm overhead in way
  command line interpreter is part-forth part-shell part-lisp
    no data-stack dependance, so no postfix parameters-first
      rather prefix recursive-descent parse arguments and options to registers
  assembler by command+defname and then instructions until end command
    code files are just command line input files that happen to compile stuff
      use "require" commands for first fetch/compiling libraries on demand
    subroutines default to compiling call, other instructions are all macros
      but also interactive needed, either 2 directories as in cm-forth
        or 2 CFA-style fields, one for each mode
    conditionals/loops as in forth, global call/var symbols from dictionary
      compile into memory, no batch style compiling, no linker, no binary files
    interactive while compiling with [ ] and compile macros with [compile]
  many commands for mnemonics of 256 or even 64k opcodes
    possibly partial-name search in dictionary, rest parse in command
      or split mnemonic in base and parameter(s), or table of all 3-char codes
      or multi-method word handler, with dict and number as last 2 techniques
    operands possibly prefix, for interactive precomputing
      this will require placing them on an stack, or fixed set of registers
      or have parser capable of entering into into [ ] for numeric value
  "monitor" functions, register dump and modify, memory dump and modify, disass
    user register state restore/run/save, NMI break, single stepping timer IRQ
    also ctrl-T for dump current running state and then continue
possibly no "disk" space, no external chips, not even an 8pin chip
  automatic disassembler for listing out, so no source code files needed
    building on that "list entire state, code and data" for backups
  editor with load/save via disass/asm, similar to lesspipe
  in this case namespace management will be needed, to separate programs
  this will also make buddy allocation style memory management necessary
possibly building on asm also interactive HLL compiler, algorithmic syntax
  can not be an traditional batch-assuming language, make own, or adapt basic
  also interpreters, activated by "#!" style call at top, followed by ascii
    saves making an compiler/decompiler, but slower, ok for a lot
    but better actually use quick compile, run and forget sequence
desirable programs infrastructure, terminal char and graphics, shell, compiler
  file/filesystem tools, pipe processor, archive/compress
  editor/viewer, dired/view, ping/trace, mail, web
console multiple possibilities, depending on hardware
  in beginning only one console, after adding multithreading allow multiple
    starting up test if console is attached, else autostart main program
      if attached go into command line, have user trigger or step program
  software bit shift over existing flash programming pins/connector
  UART RS232 over given specialised pins, are possibly part of progr connector
  if usb device, offer an type of ttyu* known to linux, and so to cu/minicom
    initially after boot one ttyu*, command to make further ones appear
    usb may be low speed 1.5mbit/s, which allows usb device in SW on 8bit uC
  possibly ethernet offer an ssh port, with some kind of sshd-like daemon
  if running as process in linux VM, use stdin/out VT terminal or own X window
    in later case own "xterm" using the graphical device, with own font