[Mono-dev] idea summary: Swing in Mono?...

[BGB]

----- Original Message ----- 
From: "Chris Toshok" <toshok at gmail.com>
To: "Stefanos A." <stapostol at gmail.com>
Cc: "BGB" <cr88192 at hotmail.com>; "Michael Hutchinson" 
<m.j.hutchinson at gmail.com>; <mono-devel-list at lists.ximian.com>
Sent: Monday, February 09, 2009 6:06 AM
Subject: Re: [Mono-dev] idea summary: Swing in Mono?...


> Yeah, I really don't understand the aim of this thread.  It seems you
> are trying to decide how to write a cross VM (of which you are
> *writing* a jvm and CIL vm?), cross platform, cross ui framework.  Or
> at least that's what I've understood, anyway.  Perhaps being a little
> more specific about things with us would help us understand exactly
> where you're going.
>

well, I have my "main project", which is basically around 300-400 kloc or so 
of misc code (a lot of 3D stuff, ...).

and, my VM effort, which is about 250 kloc.
now, my VM is a VM or sorts, but has a very different architecture from 
Mono...
the partial reason is that my VM (subproject) started off originally as a 
script VM, which was then transformed into a dynamic C compiler, and which 
then has had ever more functionality added on...

so, C code was compiled at runtime, and over time I added GC, dynamic typing 
support, an object system, ... the C remained, but all this additional stuff 
became APIs. internally, the C compiler produces code fairly similar to what 
might come out of GCC or similar, and at one point, I was benchmarking them 
and getting similar performance (although GCC had a clear speed advantage 
for floating-point scalar code, ...).

most of the code is implemented in a more-or-less modular fashion (the idea 
of one area of code messing with or depending on structs/data/code/... 
belonging elsewhere is just distasteful...). and, more so, most APIs have a 
more or less defined API (many of which have been influenced in terms of 
design and conventions by the likes of OpenGL and POSIX, namely, the empasis 
being on abstraction).

performance is also a concern, but as I see it not even performance should 
allow violation of modularity (although it may allow designing the API to 
allow as much performance as is reasonable).

the compiler in general has components similar to those of a traditional 
compiler, and is more or less divided into independent modules along these 
lines. for example, my upper compiler produces an IR (I call RPNIL, and it 
sort of resembles Forth or PostScript hybridized with COBOL...), then my 
middle compiler produces ASM (in an NASM/Intel style syntax), and my 
assembler produces objects, and my linker links them (actually, the 
assembler and linker share the same library, and are not completely isolated 
in terms of their internals).

the frontend of the compiler then orchestrates the process by sending input 
into one component, then taking the output from that component and feeding 
it into the next, ...


the core of the C compiler remains, but is being gradually reworked so that 
it can handle JIT for both JBC and CIL (along with most of the rest of the 
framework). granted, both JBC and CIL are fairly similar at this level, but 
are a good deal different than what is needed for C.

note that I decided to actually integrate most of the extended functionality 
directly into the existing compiler machinery, rather than more-or-less 
translating the JBC into something like if the code were written in C (AKA: 
bunches of hackery and API calls), because if the compiler supports all this 
natively this is cleaner and allows better performance.


so, going forwards, I more or less just implemented a JVM on top of all this 
(as another module), but currently it is not yet complete: it does not 
handle exceptions and the JIT is not complete, but it does have an 
interpreter.

CIL will likely come later than JBC, mostly because JBC is the one requiring 
less implementation work, and most of what would go into making JBC work 
would be easily adaptable to CIL.


note that the compiler machinery does not directly accept JBC (or later, 
CIL) output, nor does it directly accept the specifics of these formats, 
more the JIT process (owned by the mini-VM) converts the JBC or CIL into my 
compilers' IR, which then goes through all the machinery as before (so, the 
internal changes to the compiler are more in terms of adding capabilities to 
the IR).


now, elsewhere in the project, there is a bunch of 3D stuff, and this is 
what I use the compiler framework mostly as a big elaborate scripting 
engine.


now, as I see it, a GUI framework runs on top of a VM, and stuff running on 
top of a VM should not depend on the internals of the VM on which it runs 
(if possible).

but, as is, I have some GUI code, but it is written in C, and is part of the 
3D engine's GL-related utility functions.

I lumped together all the basic drawing stuff (text rendering, GUI, 
image/texture loading/saving, ...) into a single library.

then, most of the purely 3D-engine specific stuff (model rendering, 3D 
animation, scene graph, ...) into another library.

..