[Mono-dev] greetings (new here)... a few things...

[BGB]

[merging responses here...]


----- Original Message ----- 
From: "Seo Sanghyeon" <sanxiyn at gmail.com>
To: "BGB" <cr88192 at hotmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Tuesday, January 06, 2009 7:07 PM
Subject: Re: [Mono-dev] greetings (new here)... a few things...


> 2009/1/6 BGB <cr88192 at hotmail.com>:
>> how much does mono depend on the specifics of its existing CLI / JIT
>> implementation?...
>> how much does it depend on Boehm and like?...
>
> Are you mostly interested in class libraries? As far as I know, Mono
> class libraries depend on "internal calls", and not much else. See
> also docs/internal-calls.
>

hmm...

well, I have not yet examined the class libraries in much detail, but if 
they depend to heavily on the VM particulars, it may be a bit more effort...

but, alas, there are several possible .NET based projects I could mine parts 
from, in the worst case (doing something purely homebrew would be hopefully 
avoided, as then I am the only one working on it, and I am well aware of 
"this" sort of isolation...).

(whatever dependencies there are, I would like to be able to hopefully 
discover and consider).


but, anyways, I am hoping I don't just end up wasting the time of the people 
here, but this is always a risk I guess...


----- Original Message ----- 
From: "Robert Jordan" <robertj at gmx.net>
To: <mono-devel-list at lists.ximian.com>
Sent: Tuesday, January 06, 2009 7:26 PM
Subject: Re: [Mono-dev] greetings (new here)... a few things...


> BGB wrote:
>>
>> I am also not all that likely to re-use the existing CLI engine, as
>> personally I find the code... displeasing...
>
> You might not be aware of it, but you're suffering from a declining
> not-invented-here syndrome ;-)
>

I regularly do NIH, but partly this is because I am fairly fussy about some 
things...


I also feel that it is of some value to have multiple implementations of 
things available, and to be able to mix and match parts to get the desired 
results, so as I see it, NIH is not purely a bad thing, even if, yes, it is 
not the most direct way to do things...

this is after all, a good reason to have standards...


I don't mean to try to rip on the existing codebase that much, but it is not 
quite how I tend to do things personally.

after all, what has been achieved thus far has been impressive, which is 
more than can be said in my case. I usually end up making lots of code, 
often with a decently capable featureset, and at least as I view it, 
relatively clean coding practices, but the detractor is that code tends not 
to amount to much (I make code, but it tends to all be nothing of any real 
value...).

so, the achievements are impressive, only that is is not as easy to be 
impressed by the code in itself...


but, I expect that not everyone would like my approaches either, so that is 
ok...


> Both GC and JIT are replaceable in mono. The first is sanely
> replaceable while the latter is replaceable in theory, as
> nobody has done it publicly besides the now obsolete interpreter.
>

yes, and these are the main parts I am looking at.
not that I would do this in all cases (most of my code is specific to x86 
and x86-64, and so would not likely fulfill everyones' needs, and there are 
likely many other advantages as well).

the thing though is, I will just make much of what code I have available for 
whoever might be interested...


yes, I have looked at some of the GC machinery already, as well as some of 
the code for the object system, ...

however, as noted, a good deal more investigation is probably needed in my 
case (I have only looked over a small amount of the total codebase thus 
far).



> Mono's BCL does depend on the underlying runtime. If you want
> to replace the *whole* runtime, a lot of internal calls would have
> to be provided by the new runtime. This can be avoided by
> implementing a new JIT as mentioned above.
>
> Al this stuff can be easily discovered by reading the source and
> the docs.
>

yeah, I have looked over parts of the source, but not that much (it is 
fragmentary, much like my reading thus far through ECMA-335...).

but, yes, the kinds of calls is about as big of a question as that calls are 
needed, so I may look into this.

I did not mean to say I think that libraries are fully independent of the 
implementation, only that from the design of CIL in general, it is likely to 
be much lower than for some other frameworks (where most of the framework is 
actually implemented in C, and most of what exists in the language is thin 
wrappers over the big mass of C...).



----- Original Message ----- 
From: Alan McGovern
To: BGB
Cc: mono-devel-list at lists.ximian.com
Sent: Tuesday, January 06, 2009 8:20 PM
Subject: Re: [Mono-dev] greetings (new here)... a few things...

>
>> I am also not all that likely to re-use the existing CLI engine, as
>> personally I find the code... displeasing...
>
> The time taken to submit patches to make the code pleasing to you would be 
> significantly less > than the time taken to rewrite from scratch. If the 
> patches are good, they'll be accepted. Why > not give that a shot and see 
> if you can advance your own project *and* mono at the same
> time, at a much much faster rate than you could by by rewriting from 
> scratch. Just my
> opinion ;)
>

the issue is, I am not sure if what I would want done could be accomplished 
within reasonable effort limitations using the existing code as a base 
without probably breaking much of it in the process (nor do I feel this 
would probably be to the best interests of either project).


it makes more sense as I see it, to try to establish clearly where are the 
lines of demarcation (this has proved difficult thus far, finding out 
exactly where one component ends and the next begins, ...), and where the 
code can be carved apart without too much pain, and then try to keep in mind 
who owns what, who is the authority over which features, and so on...


sadly, the way I do most things is different...


but, alas, ECMA-335 does not look like the simplest of technologies to 
implement, and I say this while claiming to be not entirely new to either 
compilation or JIT...

after all, it is not exactly difficult to severely underestimate the amount 
of work required for a project (especially when it comes to compilers and 
similar it seems...).


so, I am not trying to say that I think any of this is a trivial matter...

FWIW, I will mention that I have experience with doing runtime compilation 
of C code (wrote a C compiler and use C as a scripting language), and 
dynamic generation of native code for both x86 and x86-64.

however, I am personally moving away from the exact approaches used in my C 
compiler (this has proved sadly inflexible, and the core of this project was 
a component which is not so easily replacable as had originally been 
hoped...).

but, at least I have finally "given in" to a set of a few hacks that will at 
least allow me to target the thing to x86-64 (and my endless lame 
complaining about the SysV calling convention... which proves to be a piece 
of technology not easily targetted "effectively" by my existing skills, 
which is probably just sad...). I end up not even targetting the arch in a 
"good" manner, just resorting in some crude hacks to get it to work.


but, oh well...


> Alan.
>