C
cr88192
well, this is a general announce. I have sent it to which groups I think
might be appropriate for this announce...
here is a site with some generic info:
http://cr88192.dyndns.org/bscc.html
and here is the updated compiler (essentially, a project dump):
http://cr88192.dyndns.org/2009-06-02_bscc.zip
it has been a while, but hopefully this is interesting.
note: I make no claims that this is "rock solid" or anything of the sort,
none the less, it could be useful, or at least maybe interesting to look
at...
basic quick summary:
it is a huge mass of code and libraries basically for something amounting to
a C-based VM, but with some work underway to support additional languages
(C++, C#, Java, and ECMAScript at present...). it differs from traditional
compilers in that it does all of the compiling and linking at runtime (and
so, it is possible to compile and run programmatically generated source
fragments, ...).
it also aims to try to avoid what I see as inherent limitations with many
existing VM efforts (such as the JVM and .NET), primarily their tendency to
create centralized and closed worlds (as well as not giving so much
"freedom" as to how the features of the VM itself may be used, ...). so, it
may be compared to a reflective VM, where the code in the VM has access to
all the same machinery making up the VM itself, as well as the mass of
"everything that exists" in good old C land.
it is neither my desire, nor ideal, that people should have to sit around
rewriting or wrapping huge masses of code and libraries to work with some
framework. rather, the framework should be open to a point that none of this
is needed.
a few key poinys:
it is written in C;
the intent is to be modular, and retain compatibility where possible with
existing technologies (as such, ASM, COFF, and ELF, are supported
input/output formats, and GNU-AR is supported for input).
x86 generally works, x86-64 is mostly untested, no other archs at present;
it has a runtime library with many "useful" features;
note that, since the language is C, and the runtimes are all C, all the
runtime stuff can be freely (and typically is) used from good old
statically-compiled C.
I have also been "trying" to keep the code clean (granted, this is secondary
to "make it work"). where appropriate, I have put effort in trying to create
clean and general-purpose APIs. I will comment that both POSIX and OpenGL,
among others, have been notable influences on my API design philosophy...
(secondarily, I want to keep the backend code, at least theoretically,
easily replacable without breaking whatever depends on it...).
it can be noted that the framework gains some ability (via header mining) to
use "reflective" capabilities on good old statically-compiled C, such as
dynamic lookups and access, and the ability to make use of metadata to
perform tasks, such as automatically doing argument marshelling for (mostly)
arbitrary function pointers (similar to a LISP style "apply"), ...
(header mining is used to fill propagate metadata in the "metadata manager",
which at present uses a structure roughly comparable to the 'Windows System
Registry'...).
an object system is provided which is simultaneously capable of:
Multiple Inheritence; Interfaces (different mechanisms from MI); and
Prototype-OO (ability to add fields and methods to individual object
instances). note that the Class/Instance Single-Inheritence + Interfaces is
presently the most optimized (MI and P-OO are not free, and will impact the
objects in question, as well as attempting to dynamically modify runtime
object layout, ...).
as can be noted, it is all "a work in progress".
I have started some work on a new IL, essentially an adapted and highly
stripped-down variant of GIMPLE, for which it could be possible later to
make a GIMPLE bridge (which could allow, among other things, the option of
eventually using LLVM as the backend code generator, ...).
(though uncertain, GIMPLE may be an eventual option for frontend compiler
output, just as is, it is still too high-level for direct use by my codegen
and so would require writing additional "middle end" machinery...).
the new IL would also help clear up some issues thus far preventing my use
of JBC (Java ByteCode), and CIL (.NET's 'Common IL'...).
note that my Java and C# frontends are, at present, being implemented as
full compiler frontends, and not as bytecode bridges.
or such...
might be appropriate for this announce...
here is a site with some generic info:
http://cr88192.dyndns.org/bscc.html
and here is the updated compiler (essentially, a project dump):
http://cr88192.dyndns.org/2009-06-02_bscc.zip
it has been a while, but hopefully this is interesting.
note: I make no claims that this is "rock solid" or anything of the sort,
none the less, it could be useful, or at least maybe interesting to look
at...
basic quick summary:
it is a huge mass of code and libraries basically for something amounting to
a C-based VM, but with some work underway to support additional languages
(C++, C#, Java, and ECMAScript at present...). it differs from traditional
compilers in that it does all of the compiling and linking at runtime (and
so, it is possible to compile and run programmatically generated source
fragments, ...).
it also aims to try to avoid what I see as inherent limitations with many
existing VM efforts (such as the JVM and .NET), primarily their tendency to
create centralized and closed worlds (as well as not giving so much
"freedom" as to how the features of the VM itself may be used, ...). so, it
may be compared to a reflective VM, where the code in the VM has access to
all the same machinery making up the VM itself, as well as the mass of
"everything that exists" in good old C land.
it is neither my desire, nor ideal, that people should have to sit around
rewriting or wrapping huge masses of code and libraries to work with some
framework. rather, the framework should be open to a point that none of this
is needed.
a few key poinys:
it is written in C;
the intent is to be modular, and retain compatibility where possible with
existing technologies (as such, ASM, COFF, and ELF, are supported
input/output formats, and GNU-AR is supported for input).
x86 generally works, x86-64 is mostly untested, no other archs at present;
it has a runtime library with many "useful" features;
note that, since the language is C, and the runtimes are all C, all the
runtime stuff can be freely (and typically is) used from good old
statically-compiled C.
I have also been "trying" to keep the code clean (granted, this is secondary
to "make it work"). where appropriate, I have put effort in trying to create
clean and general-purpose APIs. I will comment that both POSIX and OpenGL,
among others, have been notable influences on my API design philosophy...
(secondarily, I want to keep the backend code, at least theoretically,
easily replacable without breaking whatever depends on it...).
it can be noted that the framework gains some ability (via header mining) to
use "reflective" capabilities on good old statically-compiled C, such as
dynamic lookups and access, and the ability to make use of metadata to
perform tasks, such as automatically doing argument marshelling for (mostly)
arbitrary function pointers (similar to a LISP style "apply"), ...
(header mining is used to fill propagate metadata in the "metadata manager",
which at present uses a structure roughly comparable to the 'Windows System
Registry'...).
an object system is provided which is simultaneously capable of:
Multiple Inheritence; Interfaces (different mechanisms from MI); and
Prototype-OO (ability to add fields and methods to individual object
instances). note that the Class/Instance Single-Inheritence + Interfaces is
presently the most optimized (MI and P-OO are not free, and will impact the
objects in question, as well as attempting to dynamically modify runtime
object layout, ...).
as can be noted, it is all "a work in progress".
I have started some work on a new IL, essentially an adapted and highly
stripped-down variant of GIMPLE, for which it could be possible later to
make a GIMPLE bridge (which could allow, among other things, the option of
eventually using LLVM as the backend code generator, ...).
(though uncertain, GIMPLE may be an eventual option for frontend compiler
output, just as is, it is still too high-level for direct use by my codegen
and so would require writing additional "middle end" machinery...).
the new IL would also help clear up some issues thus far preventing my use
of JBC (Java ByteCode), and CIL (.NET's 'Common IL'...).
note that my Java and C# frontends are, at present, being implemented as
full compiler frontends, and not as bytecode bridges.
or such...