[Mono-dev] Ideas for Mono on Windows

[BGB]

  ----- Original Message ----- 
  From: Rafael Teixeira 
  To: SuperCiccio 
  Cc: mono-devel-list at lists.ximian.com 
  Sent: Friday, January 23, 2009 10:43 PM
  Subject: Re: [Mono-dev] Ideas for Mono on Windows


  You can try to use Mono's VM image which is an tailored-OpenSUSE, upgrading it to newer mono releases or using it to build and run mono from svn trunk is far easier than building mono in windows. 

  It also may help you find real portability issues, like what happens when the linux user doesn't have the fonts you use in your WinForms, or file access issues..

IMO, a major source of the building issue is likely the GLib dependency (or, at least, a kind of GLib-dummy can be provided).

if one can eliminate most of the dependency on libraries and tools which don't work well, or are not present, in a typical Windows environment, it should build easier.

for example, trying to get it to build in my case, required going and getting bison, and then trying to get this to build, but then having to go and tweak this as well to make it build (due to Windows not having API calls like 'fork()', ...).


but, in my case, none of this looks good to me, as I have a policy of doing more or less self-contained (and modular) code, such as that apart from areas defined to have a dependency (usually as a basic part of their operation), there are not dependencies. even then, dependencies are often wrapped such that things can be "re-routed" if needed, ...

IMO, it makes the code cleaner, easier to maintain, and easier to port (ok, yes, it is sad that much of my current project has dependencies on the x86 and x86-64 instruction sets... but it is not so easy to abstract automated code generation from the particular arch...).

(and also, my effort is much easier to build on Windows, as I code mostly for Windows...).


but, alas, my effort continues, although granted being able to JIT higher-level bytecode formats is posing many subtle difficulties.

a recent example is that, both JBC and CIL are different enough from the way my existing approach works (and is backwards of the typical "C-order" on x86 and x86-64, ...), that I considered things and made a decision to go over to a custom calling convention for these cases.

this calling convention differs in some fairly major ways from cdecl and sysv and similar, primarily in that it uses an explicit frame structure and is based around CPS (the CPU stack then is used primarily for calculations and for "native" calls).

however, I am mildly worried about the performance (for code with large numbers of small functions, the performance is not likely to be good). at least on the upside, the convention itself is only trivially different between x86 and x86-64 (the main difference being whether to use EAX or RAX, ...).

but, alas, I am not sure if Mono went and also paid the costs of using frames, ... or if it managed to keep all this stuff strictly on the CPU stack.


BTW, for my uses, I have also gone and come up with an "alternative" representation for the metadata (apparently the need for metadata being an almost inescapable issue). my representation differs somewhat from that used in CIL, namely that as opposed to using tag-indices and tables, I am using a pointer-and-value compression scheme (mostly differential pointers and VLC).

I had realized that using raw pointers, ... the space overhead of metadata would likely be huge, ... but tables require keeping track of the table structure, which would be a big hassle and probably a performance cost, so the idea then was to instead use a special coding scheme to allow the pointers to be compressed while still keeping their independence...

in general though, these pointers are not visible to the linker (note, all this is at the ASM/machine-code level), so any external pointers are typically stored in a special metadata entry, which holds linker-visible (AKA conventional) pointers (these would be pointers into code or data, or other chunks of metadata).

but, it does save from me having to make my linker aware of these oddities (actually, I am not even sure if it would be practical/possible to link this kind of pointer-compressed data, as trying to do so is likely to involve having to restructure the whole thing...).

note that the metadata is still byte-structured (no LZ or Huffman, ...) and so it is still possible for machine code to hold pointers into the metadata (likewise, the representation can be easily decoded "in place", .. at the cost of some loss of compression ability).

(none the less, a field definition could be concievably stored in 5-7 bytes, as opposed to 20 or 32 on x86 or x86-64).


note that it will not likely be a 1:1 transcription of CIL metadata, but is actually likely to be built by the JIT compiler (which may have in turn have gained its information from CIL, or also from '.class' files, ..). technically, it is structurally closer to the contents of '.class' files than CIL metadata (and the compression scheme would not likely work as well if one tried to map them 1:1), but oh well...

it is also much less complicated IMO than DWARF...

or such...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090124/73a83364/attachment.html