llvm and .NET or lisp

3.20: addx/llvm and .NET or lisp:

. how did llvm fit in with .net?
the .net was an improvement over bytecode;
it had a binary format of high-level code
-- call it wordcode --
and any language could compile to that wordcode .
. there's security in the wordcode,
since it's easy to verify it's not malware,
then a platform-specific runtime can
translate wordcode into an exec.file .
. llvm presents itself as the universal asm.code
(source code of a machine instruction set)
so one quick way to roll a wordcode compiler
is to compile wordcode to asm.code .
. then the llvm for that platform
will do all the heavy lifting of
jit-compiling and dynamic morphing
that keeps the asm.code mirrored in
the most efficient version of native code
for the current circumstances .
. there need be no practical difference between
word.code and the etrees of lisp
and perhaps that's why Stallman would
downplay .net as a Microsoft false freebee .
. what we really need from .net
is something more lisp-like
where the only constant to the std
is that etrees describe the conventions
of the current package .
. what we really need from lisp
is the same binary std for word.code
that .net calls assemblies .
. at the moment lisp's std is text-based
not binary -- xml is the same thing:
people should be communicating with that
only as a last resort,
when no binary convention has been agreed upon .
3.23:
. Mono from SVN is now able to use LLVM as a backend .

3.22: addx/security/review:
. what was the system that offered better security than
soa's token-based (smart-carded) logged messaging ?
. how did it differ from virtualization ?
. the first wall starts with using source code
rather than binaries:
. a program is an adda binary
that is then compiled to addx code
which is native code but can access only addx
(assured from being compiled by adda),
and then only addx can access actual devices .
. with this separation of power,
the program can tell addx what it needs
and then the user can tell addx
whether those needs sound reasonable .
. an adda binary is an etree (a parse tree)
where half of the compilation is already done:
. after adda text is parsed into etrees,
the etrees are safely translated by adda
to a system lang for compilation into a native binary .
. in essence the adda program has written the program;
if the original author had
programmed in the system lang'
then it could unsafely have
direct access to the machine .
. this is not unlike the .net security strategy;
but, addx is not concerned about supporting
multiple source lang's . [3.31: nevertheless,
adda's etree could be the target of
some other lang's compiler, for piping:
[your lang] -> adda`etree -> [some adda`backend] ]
. both { .net, adda } have a binary format
for sharing code, but .net's assemblies
may be more thoroughly processed than parse trees .
[3.31: and conversely, parse trees are in a
more modifiable, machine-comprehensible state
than .net's assemblies .]
. the ideal situation is to translate adda etrees
directly into llvm code,
but the easiest way to build addx in a portable way
is translating adda etree to the source text
of the language that the target platform prefers;
eg, when on the mac, the target language is
c, obj'c, and the cocoa framework;
while on linux and elsewhere,
it would be c, c++, and the qt framework .

. on the Android OS, the main source of
security is a slow vm
that compounds the speed hit caused by
addx's security not allowing
direct access to anything;
addx is asking every cross-module communication:
"(who are you,
and do you have permissions for that?)
. then if addx is to run dynamically modified code,
it's running a vm within a vm,
and things get even slower!

. the .net idea of security is much faster
than any vm security (even Dalvik)
but perhaps that speed
would come at the cost of space
-- the Android fits within 64mb .
. or,
perhaps because of patents,
any open system that was like .net
would not be easy to defend .
. the primary reason I'm not bothering to check
is that .net's idea is not nearly as simple as mine!
. you can avoid a lot of low-level programming
if you just learn the target's high-level language,
and do a simple lang-to-lang translation .
[3.31:
. actually what .net is essentially doing is
unpacking assemblies into etrees,
checking them the way adda would,
then translating them to
the etrees of some native compiler,
and compiling them dynamically .
. it's that dynamics that gives it the name .net;
that's the basis for dynamically accepting code
from other websites in a safe way .
. it may not need to get low-level,
but translating between etree formats
is definitely more complex than source-to-source .]