sablevm-developer

[Sablevm-developer] Status question(s)

[Grzegorz P. <gr...@se...>]

Hi!

A couple of questions of "where are we" kind...

1. I have seen some PowerPC patches on this list.
I even can find some PowerPC bits of this kind:

static inline void
_svmf_iflush (_svmt_word *pword)
{
#if   defined(__powerpc__)

  __asm__ __volatile__ ("dcbst 0,%0; sync; icbi 0,%0; isync"::"r"
(pword));

#elif defined(__i386__)
  /* do nothing */
#else
#error
#endif
}

Questions:
What stops us from getting PowerPC port ready?
What about other arches?
Which ones should we handle here, in _svmf_iflush (spparently)?
Which ones surely don't need this special treatment?

2. There are still problems w/ -native build-depending on
itself. It's very annoying especially while porting to new arches
(bdale was extremly helpful here, as he first installed "bad" -native,
then I rebuilded -native and he installed "good" version).
Not to mention auto-builders which won't be able to build the
package for the first time on new architecture.

Questions:
Any ideas how to fix it?
Etienne - do you have plans to remove this issue?
If yes - when can it be expected to happen?

3. I was looking at all the special, architecture-dependant
stuff in sablevm (at those "bits" I'd better say).

It seems that almost all of this could be fully automated,
so that we didn't need to do anything or almost anything to
build it on any new Linux port. Test program I attached is one of
two approches, first which I _have_ done - was to use ./configure
script to detect right types for our sizes of data.

Questions:
Do you think is it worth the effort?
Are the architectures expected to differ in some other manners
which would make this "automation" unneeded?

4. What will be needed to get this "faster" threading engine
working on non-i386 arches? (where should I start?)

Best reagards

					Grzegorz B. Prokopski

Re: [Sablevm-developer] Status question(s)

[Mark W. <ma...@kl...>]

Hi,

On Fri, 2002-10-11 at 21:43, Grzegorz Prokopski wrote:
> 

> Questions:
> What stops us from getting PowerPC port ready?

The patches that I posted get "Hello World" working.
See
http://sourceforge.net/mailarchive/forum.php?thread_id=983089&forum_id=4154
http://sourceforge.net/mailarchive/forum.php?thread_id=1006086&forum_id=4154
But there are probably some other endian issues.

I have not have the time check what does and what does not work since I
am a bit busy at the moment. But now that Hello World works someone with
some more PowerPC or endian knowledge should get most of SableVM
working.

If you have time it would be interesting how much of the Mauve test
suite you can get working on the different platforms.
See http://source.redhat.com/mauve/.

Cheers,

Mark

Re: [Sablevm-developer] Status question(s)

[Etienne M. G. <eti...@uq...>]

On Fri, Oct 11, 2002 at 09:43:28PM +0200, Grzegorz Prokopski wrote:
> 2. There are still problems w/ -native build-depending on
> itself. It's very annoying especially while porting to new arches
...
> Any ideas how to fix it?
> Etienne - do you have plans to remove this issue?
> If yes - when can it be expected to happen?

I have to understand the problem, first.  As I don't have an infinite
amount of time to work on all issues, we will have to start
prioritizing tasks.

I currently see the following things to do:

1- Fill the holes in reflexion support for getting the most important
Debian Java apps to work (or at least "Ant").

2- Fill the holes in JNI and Invocation Interface (e.g. clean
DestroyVM, etc.)

3- Look at the AWT stuff, and see if we can get some of it to work.

4- Discuss some formatting issues (e.g. indentation, directory
structure) with the Classpath project so that official Classpath could
work out-of-the-box with SableVM.

5- Solve the multiple-achitecture GNU auto* tools problems you are
raising in this message.

6- Port SableVM to all (or most) Debian architectures.

7- Make sure the "inline-threaded" engine woks on all these
architectures.


Here are the main points I see for the moment.  Have I forgotten
anything?

> 4. What will be needed to get this "faster" threading engine
> working on non-i386 arches? (where should I start?)

First, we need an "iflush()" on them.  Then, it depends.  It might
work out-of-the box on some architectures, or some others might
require playing with the "INLINEABLE" property of some bytecodes
(instructions.m4.c).

OK, I'll be checking mail only on Sunday.  Have fun!

Etienne
> 
> Best reagards
> 
> 					Grzegorz B. Prokopski
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Status question(s)

[Grzegorz P. <gr...@se...>]

W li=B6cie z pi=B1, 11-10-2002, godz. 22:02, Etienne M. Gagnon pisze:=20
> 5- Solve the multiple-achitecture GNU auto* tools problems you are
> raising in this message.
Could you please move it to the front of the list?
I'd very much like to soon upload version which compiles on all
arches, on which build-deps are fulfilled. And it would be
*very* bad to be forced to workaround this self-build-dep thing.

> 6- Port SableVM to all (or most) Debian architectures.
It's mine topic for now, so on your list it can stay where it is.

> 7- Make sure the "inline-threaded" engine woks on all these
> architectures.
I hope to work together on this topic.


> > 4. What will be needed to get this "faster" threading engine
> > working on non-i386 arches? (where should I start?)
> First, we need an "iflush()" on them.  Then, it depends.  It might
> work out-of-the box on some architectures, or some others might
> require playing with the "INLINEABLE" property of some bytecodes
> (instructions.m4.c).
I'll have to learn more about that asm code for powerpc to catch
how to implement it on other arches.

> OK, I'll be checking mail only on Sunday.  Have fun!
Sure, I am busy too. I have second studies to study on weekends too.

Best regards

					GBP

Re: [Sablevm-developer] Status question(s)

[Etienne M. G. <eti...@uq...>]

Hi Grzegorz,

On Fri, Oct 11, 2002 at 11:20:58PM +0200, Grzegorz Prokopski wrote:
> W li?cie z pi?, 11-10-2002, godz. 22:02, Etienne M. Gagnon pisze:=20
> > 5- Solve the multiple-achitecture GNU auto* tools problems you are
> > raising in this message.
> Could you please move it to the front of the list?


I forgot to say: my list was *unordered*.  I was just trying to sum up
all the "todo" work, and asking people for some ordering.  I guess I
should put "5-" at the top. ;-)

Etienne

--=20
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Status question(s)

[Grzegorz P. <gr...@se...>]

W li=B6cie z pon, 14-10-2002, godz. 02:48, Etienne M. Gagnon pisze:=20
> On Fri, Oct 11, 2002 at 11:20:58PM +0200, Grzegorz Prokopski wrote:
> > W li?cie z pi?, 11-10-2002, godz. 22:02, Etienne M. Gagnon pisze:=20
> > > 5- Solve the multiple-achitecture GNU auto* tools problems you are
> > > raising in this message.
> > Could you please move it to the front of the list?
> I forgot to say: my list was *unordered*.  I was just trying to sum up
> all the "todo" work, and asking people for some ordering.  I guess I
> should put "5-" at the top. ;-)

Yes, please. It is somewhat critical. And:
1. release more current 1.0.5 w/ ia64 and other your improvements
2. tell me what you think about totally-auto-config patch ( I agree
that #if GNUC should stay, but what about the rest? the main?)

ad 1. It's non-critilal - at least for me and I am more interested in
ad 2. I'd like to push this thing further as the testing here will
take time. We need to put the patch onto autobuilders, see what's
breaking, fix stuff, upload again, package mauve, ask users of
all arches to use mauve tests.

Hmm... I just thought about sablevm-test package. It could
build-dep on sablevm, mauve and other needed pieces and
while building - it could just run all the tests we can be
interested in. Of course it would be autobuilded (or I'd better
say "autotested") on _all_ of debian architectures thus - making it
easy to run any test we can dream of ;-))

I think I prepare the package quickly (this week) so that ftpmaster
had time to let it in.

Regards

				Grzegorz B. Prokopski

Re: [Sablevm-developer] Status question(s)

[Grzegorz P. <gr...@se...>]

W li=B6cie z pi=B1, 11-10-2002, godz. 21:52, Mark Wielaard pisze:=20
> Hi,
>=20
> On Fri, 2002-10-11 at 21:43, Grzegorz Prokopski wrote:
> >=20
>=20
> > Questions:
> > What stops us from getting PowerPC port ready?
>=20
> The patches that I posted get "Hello World" working.
> See
> http://sourceforge.net/mailarchive/forum.php?thread_id=3D983089&forum_id=
=3D4154
> http://sourceforge.net/mailarchive/forum.php?thread_id=3D1006086&forum_id=
=3D4154
> But there are probably some other endian issues.
It seems that conversation dried up in "Another small step on powerpc"
thread. No final conclusion was made AFAICS.
However if you got Hello Word working what other problems arosed
(with bigger apps I suppose). Do you have any output of such problem?
(I mean things that work w/ SableVM on i386 but not powerpc).

> I have not have the time check what does and what does not work since I
> am a bit busy at the moment. But now that Hello World works someone with
> some more PowerPC or endian knowledge should get most of SableVM
> working.
Huh - so you say we're having endianness problems w/ SableVM?
Hmm.. it seems that all - i386, alpha, ia64 have same endianness.
It is interesting how SableVM will work on new platforms after we add
auto-configure on Linux platforms.

> If you have time it would be interesting how much of the Mauve test
> suite you can get working on the different platforms.
> See http://source.redhat.com/mauve/.
Yes, I have just ITP:ed this test.

After we have SableVM compiled on all arches - we'll have to ask
users (or rather debian developers) to test it. So it'll be needed
to have mauve test around in packaged form.

Thanks for the pointer and all your effort

				Grzegorz B. Prokopski

Re: [Sablevm-developer] Status question(s)

[Mark W. <ma...@kl...>]

Hi,

On Mon, 2002-10-14 at 22:30, Grzegorz Prokopski wrote:
> It seems that conversation dried up in "Another small step on powerpc"
> thread. No final conclusion was made AFAICS.

Yes, sorry. I ran out of time. Learning and hacking powerpc assembly and
figuring out calling conventions is fun but very time consuming.

> However if you got Hello Word working what other problems arosed
> (with bigger apps I suppose). Do you have any output of such problem?
> (I mean things that work w/ SableVM on i386 but not powerpc).

I don't have a powerpc build around at the moment. But also on x86 you
get things like:
sablevm: INTERNAL ERROR (source file "native_interface.c", line 24046):
todo
But I believe Etienne is working on those.

> > I have not have the time check what does and what does not work since I
> > am a bit busy at the moment. But now that Hello World works someone with
> > some more PowerPC or endian knowledge should get most of SableVM
> > working.
> Huh - so you say we're having endianness problems w/ SableVM?
> Hmm.. it seems that all - i386, alpha, ia64 have same endianness.
> It is interesting how SableVM will work on new platforms after we add
> auto-configure on Linux platforms.

I believe there are some places that need investigating (like the one
mentioned in my patch). It seems to be mainly passing arguments and
getting results from calling native code through JNI that has some
problems. Programs that don't use classes with native code seem to work
OK.

> > If you have time it would be interesting how much of the Mauve test
> > suite you can get working on the different platforms.
> > See http://source.redhat.com/mauve/.
> Yes, I have just ITP:ed this test.
>
> After we have SableVM compiled on all arches - we'll have to ask
> users (or rather debian developers) to test it. So it'll be needed
> to have mauve test around in packaged form.

Please let me know if you are going to use it. I can give pointers to
results with Kissme, kaffe or gcj so you know what to expect (there are
a couple of tests in Mauve that sadly fail on almost every VM and that I
expect to be wrong in the first place). But there are a couple of 

Cheers,

Mark