Thread: [Sablevm-developer] powerpc port status
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: David P. B. <db...@CS...> - 2002-12-12 17:49:08
|
Hi, I tried to port sableVM to the powerpc. I got it to compile. But it cannot execute a simple hello program. It stops and prints: java/lang/ExceptionInInitializer I does not even get to execute main. I heard from Etienne that someone else was working on a powerpc port. I would like to know its current state and, if it gets to execute the HelloWorld program, I would like to have the source code/patch even if it is still unstable. FYI, I will develop a JIT compiler for SableVM for my master degree. Emphasis will be made on portability. I am thinking of initally targetting the x86 and (PowerPC or Sparc) architectures. Thanks,=20 David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Mark W. <ma...@kl...> - 2002-12-12 23:05:11
|
Hi, On Thu, 2002-12-12 at 18:49, David Paul BELANGER wrote: > I tried to port sableVM to the powerpc. I got it to compile. But it > cannot execute a simple hello program. It stops and prints: > java/lang/ExceptionInInitializer > I does not even get to execute main. > > I heard from Etienne that someone else was working on a powerpc port. I > would like to know its current state and, if it gets to execute the > HelloWorld program, I would like to have the source code/patch even if > it is still unstable. A while ago I made some patches that got Hello World working on powerpc: http://sourceforge.net/mailarchive/forum.php?thread_id=983089&forum_id=4154 http://sourceforge.net/mailarchive/message.php?msg_id=1997083 http://sourceforge.net/mailarchive/forum.php?thread_id=1006086&forum_id=4154 They got never applied to the main source tree though. SableVM seems to have some other endian issues with invoking native code through JNI. Please let me know if the patches in those message still apply against the current tree and make at least Hello World work. I would love to have a working SableVM on powerpc but just don't have to time to hack on it (and this was the first time I did anything in powerpc assembly so I am not the best person to move this port forward). Cheers, Mark |
|
From: David P. B. <db...@CS...> - 2002-12-13 01:09:26
|
On Fri, Dec 13, 2002 at 12:04:09AM +0100, Mark Wielaard wrote: > Hi, >=20 > On Thu, 2002-12-12 at 18:49, David Paul BELANGER wrote: > > I tried to port sableVM to the powerpc. I got it to compile. But it > > cannot execute a simple hello program. It stops and prints: > > java/lang/ExceptionInInitializer > > I does not even get to execute main. > >=20 > > I heard from Etienne that someone else was working on a powerpc port.= I > > would like to know its current state and, if it gets to execute the > > HelloWorld program, I would like to have the source code/patch even i= f > > it is still unstable. >=20 > A while ago I made some patches that got Hello World working on powerpc= : > http://sourceforge.net/mailarchive/forum.php?thread_id=3D983089&forum_i= d=3D4154 > http://sourceforge.net/mailarchive/message.php?msg_id=3D1997083 > http://sourceforge.net/mailarchive/forum.php?thread_id=3D1006086&forum_= id=3D4154 >=20 > They got never applied to the main source tree though. SableVM seems to > have some other endian issues with invoking native code through JNI. >=20 > Please let me know if the patches in those message still apply against > the current tree and make at least Hello World work. I would love to > have a working SableVM on powerpc but just don't have to time to hack o= n > it (and this was the first time I did anything in powerpc assembly so I > am not the best person to move this port forward). >=20 Hi, I got HelloWorld to work on sablevm 1.0.5! I got it to work by applying your patch for native.c to the code I have previously hacked. Now I will compare your patches for the other parts with mine and run more tests. Thanks, David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 01:20:18
|
On Thu, Dec 12, 2002 at 08:09:23PM -0500, David Paul BELANGER wrote: > Hi, > > I got HelloWorld to work on sablevm 1.0.5! This is really great! So, were there any endianness problem you had to fix? Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David P. B. <db...@CS...> - 2002-12-13 19:46:59
|
Hello,
There something I don't quite get
native.c around line 1240:
Original code (does not work on PPC):
case SVM_TYPE_BOOLEAN:
params[0].jint =3D *((jboolean *) &result[0]);
Could it be simply replaced by (works on PPC):
params[0].jint =3D result[0].jint;
instead?
or is the address taken, cast, deference for some reason? I guess it
depends on how the data is stored in _svmt_stack_value_union by ffi_call
and how the union is layed out in memory?
David
On Thu, Dec 12, 2002 at 08:14:46PM -0500, Etienne M. Gagnon wrote:
> On Thu, Dec 12, 2002 at 08:09:23PM -0500, David Paul BELANGER wrote:
> > Hi,
> >=20
> > I got HelloWorld to work on sablevm 1.0.5!
>=20
> This is really great! So, were there any endianness problem you had to=
fix?
>=20
> Etienne
>=20
> --=20
> Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/
> SableVM: http://www.sablevm.org/
> SableCC: http://www.sablecc.org/
--=20
---
David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226
Web page: http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
|
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 22:19:03
|
On Fri, Dec 13, 2002 at 02:46:53PM -0500, David Paul BELANGER wrote: > > Hello, > > There something I don't quite get > > native.c around line 1240: > > Original code (does not work on PPC): > case SVM_TYPE_BOOLEAN: > params[0].jint = *((jboolean *) &result[0]); > > > Could it be simply replaced by (works on PPC): > params[0].jint = result[0].jint; > instead? > > or is the address taken, cast, deference for some reason? I guess it > depends on how the data is stored in _svmt_stack_value_union by ffi_call > and how the union is layed out in memory? libffi is supposed to be returning a boolean (i.e. "char") value at the location &result [at least, this is what I understood from the documentation]. So, *((jboolean *) &result[0]) seems to be "the right way" to extract the returned boolean value. Nowhere, in the libffi doc, have I see any special note about handling sub-32bits values specially (because of alignment constraints), so I suspect libffi is buggy. Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David P. B. <db...@CS...> - 2002-12-13 22:18:46
|
I found the source of the problem: If you have: int v =3D 0x1234ABCD; On x86: (unsigned char) v and (unsigned char*) &v are both equivalent. Both will return byte 0 of the word which 0xCD which is correct. On PowerPC (big endian) (unsigned char) v and *((unsigned char*) &v) are different. The first one will return correctly byte 3 that is 0xCD. But the 2nd one returns byte 0 which is 0x12 on a big endian. Accessing the value simply with: params[0].jint =3D result[0].jint; instead of params[0].jint =3D *((jboolean *) &result[0]); =20 and this should work if the field jint is always located at the beginning= of the union in memory. The other possible fix is to take byte at offset 3 for big endian machines: *(((unsigned char*) &v) + 3) this does not rely on the layout of the union in memory. David On Thu, Dec 12, 2002 at 08:14:46PM -0500, Etienne M. Gagnon wrote: > On Thu, Dec 12, 2002 at 08:09:23PM -0500, David Paul BELANGER wrote: > > Hi, > >=20 > > I got HelloWorld to work on sablevm 1.0.5! >=20 > This is really great! So, were there any endianness problem you had to= fix? >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 22:55:03
|
On Fri, Dec 13, 2002 at 05:18:42PM -0500, David Paul BELANGER wrote: > Accessing the value simply with: > params[0].jint = result[0].jint; >... > The other possible fix is to take byte at offset 3 for big endian > machines: > *(((unsigned char*) &v) + 3) > this does not rely on the layout of the union in memory. Yes, it actually does! So, this would be wrong, as libffi was given ((unsigned char*) &v) as the location to store a "char", not and "int". So, SableVM's source code is correct. "params[0].jint = result[0].jint;" should fail on a big-endian machine! (It makes sense for this code *not* to work on both big and little-endian machines, if a "char" value was stored at &result). Maybe we should add an "#if defined(LIBFFIBUG) ... #endif" clause with the temporary bug evasion for now, and submit a bug against libffi (try "reportbug libffi2" on Debian, assuming reportbug is installed). Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David P. B. <db...@CS...> - 2002-12-14 01:32:49
|
Hello, I will send a bug report to the libffi2 maintainers. I found another bug about libffi2. It does not passed properly args of type ffi_type_uint8. I will patch the code temporarily as suggested by Etienne to get around these bugs. David On Fri, Dec 13, 2002 at 05:49:16PM -0500, Etienne M. Gagnon wrote: > On Fri, Dec 13, 2002 at 05:18:42PM -0500, David Paul BELANGER wrote: > > Accessing the value simply with: > > params[0].jint =3D result[0].jint; > >... > > The other possible fix is to take byte at offset 3 for big endian > > machines: > > *(((unsigned char*) &v) + 3) > > this does not rely on the layout of the union in memory. >=20 > Yes, it actually does! So, this would be wrong, as libffi was given > ((unsigned char*) &v) as the location to store a "char", not and > "int". So, SableVM's source code is correct. >=20 > "params[0].jint =3D result[0].jint;" should fail on a big-endian > machine! (It makes sense for this code *not* to work on both big and > little-endian machines, if a "char" value was stored at &result). >=20 > Maybe we should add an "#if defined(LIBFFIBUG) ... #endif" clause with > the temporary bug evasion for now, and submit a bug against libffi > (try "reportbug libffi2" on Debian, assuming reportbug is installed). >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X