----- Original Message ----- From: "Chris Toshok" <tos...@gmail.com> To: "Stefanos A." <stapos...@gmail.com> Cc: "BGB" <cr88...@hotmail.com>; "Michael Hutchinson" <m.j.hutchin...@gmail.com>; <mono-devel-list@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. .. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list