Re: [sablevm-jchevm] Windows port

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1887135944==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig41E5A70DA0A621610F3F55BD"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig41E5A70DA0A621610F3F55BD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Enrico Migliore wrote:
> In any case, I think that the Windows port should rely on the pthread
> library written for Windows.
> To speed the execution time, in the future, we might want to inline the
> pthread functions used.

Thread functions, by nature, cause a context switch (OS call).  So,
inlining won't affect performance in any significative way.  I would
much prefer a clean, out-of-vm, thread porting layer.  I am no fan of
micro-optimizations, specially prior to having things up and running.

> The port is not trivial, not easy, not a quick-and-dirty work, therefore
> in order to do it right, I'm gonna make a written roadmap, based on:
> 
> 1. SableVM source code inspection

OK.

> 
> 2. libffi source code inspection

Actually, SableVM only uses a small subset of libffi's functionality.
I've always dreamt of a libjffi that simply supports JNI types.  We
could actually do this, so as to simplify porting to new platforms.  All
that's needed is ABI implementation on a target platform for passign
around simple types as function arguments.

Now, libffi does work on windows.  I would be much surprised if it
really required cygwin.  It might not be trivial to compile with
Microsoft's compiler if it uses inlined assembly.  I should look at the
source code if it does that or if it uses separate assembly source files.

> 3. popt source code inspection

As I said, we don't need to port the SableVM launcher.  Therefore, popt
is not needed.

> I also would like to make a written report of the work in order to allow
> the port of JCHEVM without re-discovering the wheel.

Agreed.  You could either use the Wiki as a draft board, or better, we
should settle the legal thingny so that you put it all into your sandbox.

Could you give a look at:

http://sablevm.org/svn/repository/sablevm/trunk/doc/contribution_policy.txt

If this is something you feel OK with, we'll do the formal things.

Etienne

-- 
Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

--------------enig41E5A70DA0A621610F3F55BD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEN9mjjyrJi4rH84gRAmdUAJ9r4WSbRX1cN6Z7VYuZccg9y/4dQwCfcKGy
xQhxm4AskS1/ziXXgbJSRpc=
=RZ9Z
-----END PGP SIGNATURE-----

--------------enig41E5A70DA0A621610F3F55BD--


--===============1887135944==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
SableVM-devel mailing list
[email protected]
http://sablevm.org/lists/control/listinfo/sablevm-devel

--===============1887135944==--