OF uncompressed DV-video streams.
http://www.codecomments.com/archive274-2004-8-253120.html
lisp machine/cpu to clisp bytecode/virtual machine
http://clisp.cons.org/impnotes/intr-set.html
http://clisp.cons.org/impnotes/vm.html
crossing instruction set question with promiscuous (or in the words of Design of LISP-Based Processors... LAMBDA: The Ultimate Opcode, an "incestuous software" realm of software manipulating software as data: "program editors, compilers, interpreters, linking loaders, debugging systems...") coding - such as at core of the viral (extreme promiscuity) - the compiler (... Trusting Trust)).
virtual shared memory model on a VM.
The bytecode can be thought of as being interpreted by a virtual processor. The engine which interprets the bytecode (the implementation of the virtual machine) is actually a C function, but it could as well be a just-in-time compiler which translates a function's bytecode into hardware CPU instructions the first time said function is called.
The virtual machine is a stack machine with two stacks:
STACK - a stack for CLISP objects and frames (Lisp stack). SP - a stack for other data and pointers (Program stack).
Also Pico Lisp looks interesting from VM POV:
http://software-lab.de/ref.html
"First of all, Pico Lisp is a virtual machine architecture, and then a programming language."
"... the one-to-one relationship of language and virtual machine of an interpreted system"
from FAQ:
Would it make sense to build Pico Lisp in hardware?
At least it should be interesting. It would be a machine executing list (tree) structures instead of linear instruction sequences. "Instruction prefetch" would look down the CAR- and CDR-chains, and perhaps need only a single cache for both data and instructions.
Primitive functions like set, val, if and while, which are written in C now, would be implemented in microcode. Plus a few I/O functions for hardware access. EVAL itself would be a microcode subroutine.
Only a single heap and a single stack is needed. They grow towards each other, and cause garbage collection if they get too close. Heap compaction is trivial due to the single cell size.
There is no assembly-language. The lowest level (above the hardware and microcode levels) are s-expressions: The machine language is Lisp.
http://www.rdrop.com/~cary/html/computer_architecture.html#simple_cpu
interesting in mention of PIC-based interpreter
(design of modular PIC system for reconfigurable audio)
see also PICBIT:
http://w3.ift.ulaval.ca/~dadub100/files/picbit.pdf
mention of CADR Verilog code
solely referenced by start and end points catalogued as contra to fm01 mantra
yet such points can be entered into the alice.lisp style representation/querying system and film generated which matches certain queries or as a functional response to an investigation
Schemix:
Schemix is implemented entirely in kernel space. It implements an arbitrary number of Scheme interpreters, each one separate from the others, and each one attached to some device in the /dev hierarchy.
http://www.abstractnonsense.com/schemix/index.html
Movitz:
The Movitz system aspires to be an implementation of ANSI Common Lisp that targets the ubiquitous x86 PC architecture "on the metal". That is, running without any operating system or other form of software environment. Movitz is a development platform for operating system kernels, embedded, and single-purpose applications. There can potentially be several completely different
operating systems built using Movitz.
More developed: http://common-lisp.net/project/movitz/
check out CVS
Algorithmic movie editing in Lisp:
http://blogs.bl0rg.net/netzstaub/archives/000831.html
https://bl0rg.net/~manuel/schnitt.lisp
The two opposing approaches:
1) Low-level modification (patching) of an existent operating system (GNU Linux, Hurd, other candidates?) or creation of x86-based
promiscuOS (virtualised a la Xen or not).
2) High-level sandboxed shared user-space a la ap0202 but as a (user-) space within which software can be compiled or interpreted and executed on a virtual machine layer which implies (an
intentionality of) leakage
...
Understanding the Linux Kernel (O'Reilly, Bovet et al.):
p376+
... the Linux Page Fault exception handler must distinguish exceptions caused by programming errors from those caused by a reference to a page that legitimately belongs to the process address space but simply hasn't been allocated yet.
do_page_fault() function (where? - arch/i386/mm/fault.c) is interrupt service routine for the 80x86 arch...
(from Linux Kernel Primer, PTR, Rodriguez et al:)
p238+
hardware interrupt 14 occurs when processor identifies the following conditions/exceptions:
(note exceptions can be classified as faults: the EIP is the address of the instruction that caused the fault - hence allowing instruction to be resumed if the condition is corrected. and if not...)
and from p183+
we find that the page tables are provided by OS to the MMU (Memory Management Unit - note lacking in sat Motorola 68000 and thus uCLinux port) to enable translation between virtual and physical addresses and to allow paging. (thus phys=virtual under uCLinux) - hardware promiscuity is perhaps promoted by this lack of abstraction, this bare equivalence.
3 bit error code is pushed on the stack by control unit when exception occurred:
do_page_fault is charged with handling possible scenarios, first up reads linear address that caused page fault.
mm_struct descriptor is for process memory
bad_area
jump to label bad_area if (what we're interested in) task's memory region does not include the address or address is not in current task's address space
thence:
is it in user_mode -> SIGSEGV
no - then jump to no_context:
if there is not an entry in the exception table for the offending instruction, we end up with oops screen dump
thus:
for promiscuOS, sharing process memory could be achieved at the level of hardware (uCLinux inspired), process memory creation (allocation) or some kind of patch to the page_fault handler (??)
Creating a Process Adress (p392+ O'Reilly)
clone, fork, shared memory space, parent space, COW...
from promiscuOS::
All process memory is (un)intentionally readable and writable by any process or user.
1] Elementary electronics p123
The bistable multivibrator. Four of these (the last three lacking a fourth transistor (NPN)) are linked on p166 to construct a binary counter which counts input pulses.
2] How does a CPU detect a memory violation?
Simple question. How it knows of memory boundaries and/of running process for SEGFAULT signal (11?) and how could succesfully override?
3] Possible Lisp-coded AVI manipulations of SALO
(of life_coding layers of quotation) for Riga presentation.