<br><br><div class="gmail_quote">On Wed, Aug 31, 2011 at 5:28 PM, Brian Alliet <span dir="ltr"><<a href="mailto:brian@brianweb.net">brian@brianweb.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Aug 31, 2011 at 01:08:26PM +0200, Yaffe, Lior wrote:<br>
> We never ported this source code to MIPS though.<br>
<br>
</div>Hopefully this shouldn't cause any issues. As long as your code doesn't<br>
make any assumptions about endianness, alignment, etc you shouldn't<br>
have any trouble.<br>
<br>
NestedVM uses newlib, a small libc designed for embedded systems.<br>
Newlib doesn't have all the features of glibc (but it does fully<br>
support ANSI C) and might cause you some trouble though.<br>
<div class="im"><br></div></blockquote><div><br></div><div>I spent a lot of time last year trying to get a large C/Fortran project to compile in the nestedvm environment and ultimately gave up and embarked on a much longer process of rewriting the code into java. NestedVM is a brilliant system but there are some gotchas:</div>
<div><br></div><div>- Newlib is the biggest block. As Brian said, it's a subset of glibc and nestedvm uses an older version which is even smaller. There is some functionality missing (iconv, threads) but also a lot of superficial differences (like no stdint.h) that take time to paper over. </div>
<div>- Your project needs to compile under GCC 3.something... (or you need to updated NestedVM to use GCC 4)</div><div>- You will need to change any dynamic linking to static linking in your project, which perhaps is only a problem if loading modules at runtime is a key part of the architechture.</div>
<div><br></div><div>I'd say the bottom line is that if your existing code base is well written and you're committed to maintaining it in C / GCC 3 / Newlib over the long term, then NestedVM would be a big win, but prepare to get your hands dirty wrestling with compilers and C defines. With my own project, I just got to the point where I decided I would rather spend the energy on rewriting in Java then jury-rigging header files and fighting with GCC 3. </div>
<div><br></div><div>Good luck!</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> Our existing code is compiled into DLL/SO file and is loaded in runtime<br>
> using JNI.<br>
<br>
</div>NestedVM's bridge to Java is totally different than JNI (although<br>
writing a JNI-like api on top of the current interface should be<br>
possible). How intertwined is your native and java code? If they mostly<br>
communicate at arms length you shouldn't have too much trouble, but if<br>
you have dozens of functions, complex data types, callbacks to Java,<br>
etc building the bridge between the two worlds will take some work.<br>
<div class="im"><br>
> Given the current status of the NestedVM product would you recommend<br>
> using NestedVM for this purpose ?<br>
<br>
</div>Yes, this sort of thing is exactly what NestedVM was designed for.<br>
<br>
The only reason I wouldn't recommend NestedVM would be if your native<br>
code was performance critical. Your native code will likely only run<br>
10%-20% as fast under NestedVM.<br>
<div class="im"><br>
> Would be able to assist us in case we run into problems or need product<br>
> modifications ?<br>
<br>
</div>Certainly.<br>
<br>
-Brian<br>
<br>
_______________________________________________<br>
Nestedvm mailing list<br>
<a href="mailto:Nestedvm@lists.hcoop.net">Nestedvm@lists.hcoop.net</a><br>
<a href="https://lists.hcoop.net/listinfo/nestedvm" target="_blank">https://lists.hcoop.net/listinfo/nestedvm</a><br>
</blockquote></div><br>