well, I was referred here by someone I know, and it seems like it it may be
possible to have interesting conversations...
granted, I am not so fammiliar at present with either this group or what
everyone here is trying to accomplish.
I was given a little doubt though by the initial descriptions I read while
looking around, in part because the basic idea of the extreme reductionism
proposed doesn't exactly seem entirely realistic to me, but oh well...
well, if it is possible, I wont object...
it could all just be because most of my projects tend to turn into small
mountains of C code. I write this as an initially small "subproject" of mine
gradually approaches 250 kloc (aka: 250,000 lines of code), mostly C, with
some parts in assembler, other parts crafting either assembler or raw
machine code, and most of the rest depending on these parts.
and part of the purpose: to improve the "flexibility" of code while trying
to avoid both the performance costs and detachment from the outside world
and similar inherent in building everything on top of a VM.
of course, this project steadily approaches becomming (or at least,
including) some of the same kinds of VMs it had sought to avoid depending on
(as another recent component is a largely written interpreter for
Java-ByteCode...).
more so, not only is this codebase written in C, but it also compiles C, and
links the newly compliled code against itself at runtime... though, sadly,
this is not as universally as "good" as originally thought (dynamically
compiling C code is not exactly cheap in terms of either time or memory use,
due not in small part to all the masses of stuff typically #include'ed each
time...).
so, yeah, most of the C code is still statically compiled, and a lot of the
more "practical" dynamic components being done in assembly (either just
dynamically assembled, or composed+assembled...).
well, most of this stuff would take too long to explain and I doubt most
here would care about most of it...
(and it is probably all one of the big ugly codebases people here are trying
to avoid, but oh well...).
a possibly interesting "personal" bit of development is me recently
implementing a class/instance system (again, mostly C with a few dyn-asm
chunks in the mix).
now, for a hopefully "interesting" part:
some ideas exist (not yet put down in code) for merging tohether a
statically-typed class/instance OO with some features from prototype OO,
without going (entirely) outside the bounds of static types...
in part, the idea would be to try to make ECMAScript and Java work on top of
the same underlying object model (and hopefully share eachothers' code and
data in a relatively seamless manner...).
note that interfaces (in the Java sense) play a fairly central role in this
part of the design (an interface can allow a loosely structured object to be
manipulated while still more-or-less within the confines of static typing).
though less simple, interfaces will also play an important rule in the
delegation semantics as well (the interface referencing some slots or
methods that may, infact, be located in different objects).
now, my reasons for using static-typing for all this stuff is not that I
dislike dynamic typing or anything, but more that general use of dynamic
typing can't deliver the same level of performance as static typing, and
performance is a goal in my case as well...
none the less, dynamic types are still included, as a type within the static
typesystem...
(granted, yes, dynamic use of static typing makes everything about 10x more
effort to implement...).
note that this is all "proper" static typing, as in actually passing floats
and doubles as floats and doubles, with no tagged references or similar
(tagged references themselves eat performance, if for no other reason than
having to endlessly fiddle with the low order bits, and very often much
more, for example, in having to have ones' doubles or longs on the heap...).
none the less, often dynamic types are the best tool for the job, and so I
use them in many cases as well.
note that this object system includes a C-usable API (I don't intend to
forsake C here).
actually, C-level performance and convinience are fairly serious goals (as
well as keeping most operations < 1 us, and many < 100 ns...).
note that most of these operations are either O(1) or have an O(1) average
case, do not use dynamic type checks, and do not allocate storage on the
heap...
the API is mutex protected / thread safe (albeit, I wrote my own mutexes
after discovering that the mutexes provided by Windows were absurdly slow,
taking far langer to lock and unlock the mutex than it would take to perform
even rather expensive operations, where I don't need 1200 ns to lock/unlock
a mutex for a 50 or 100 ns operation...). granted, I have not benchmarked
the API in mutithreaded tests as of yet (cross fingers and hope...).
in general, the API derives many aspects of its external design from JNI (no
'env' structure though). much of JNI in my case was written as a thin
wrapper over this API.
note that it is not a present goal at present to write OOP compiler
extensions for C, nor at present for me to go write a C++ compiler... (most
of my stuff is still compiled with gcc anyways, so it makes sense to leave
the object system primarily as a library feature...).
implementing a JVM is a standing goal, although this VM is likely to include
more than a few non-standard extensions (likely via a forked and modified
version of the bytecode format, which has been largely designed but not yet
implemented).
I am suspecting it may also be possible to support Tamarin/AVM2 bytecode on
the same basic VM without too much work (many of the relevant structures
seem similar between them, and many of the differences are in areas I am
already dealing with). can't say for certain if I will go this route, still
speculation at this point... (the JVM was an influence for the design of the
AVM2?... at least it looks that way from some of the things I looked at...).
well, I am not hoping here to bore everyone or to simply spam my own
efforts.
me looking forwards to hopefully having any interesting conversations...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
