Thread: Re: [Sablevm-developer] Flushing strategy ....
Brought to you by:
egagnon
From: Gunda D. <sab...@ho...> - 2002-12-11 15:14:51
|
Cool. Now for the inline-threading to work on ARM, I did look at the post on the IA-64. I will try it out in the next few days and let you know. You had mentioned about running java programs which exercises all the byte codes. Is there a benchmark/example java program which has the all the byte-codes ? Thanks. -Gunda >From: "Etienne M. Gagnon" <eti...@uq...> >To: Gunda Domlur <sab...@ho...> >CC: sab...@li... >Subject: Re: [Sablevm-developer] Flushing strategy .... >Date: Tue, 10 Dec 2002 22:43:35 -0500 > >On Tue, Dec 10, 2002 at 03:17:33PM -0700, Gunda Domlur wrote: > > Bottom-line: I think it is better off to provide iflush with a second >size > > parameter and leave the implementation specfic for a particular > > architecture implementation. > > > > What say you ? > >Agreed. > > >On another note: If you want to play with inline-threading, please try >porting the folloowing interpreter to ARM: >http://www-sor.inria.fr/~piumarta/pldi98/vm.c > >In fact, you might want to read the paper: >http://www-sor.inria.fr/~piumarta/pldi98/ >http://www-sor.inria.fr/~piumarta/pldi98/paper.ps.gz > >If you can get it to work, it should give us the base framework to get >SableVM's inline-threaded engine to work on ARM. > >Have fun! > >Etienne > >-- >Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ >SableVM: http://www.sablevm.org/ >SableCC: http://www.sablecc.org/ > > >------------------------------------------------------- >This sf.net email is sponsored by: >With Great Power, Comes Great Responsibility >Learn to use your power at OSDN's High Performance Computing Channel >http://hpc.devchannel.org/ >_______________________________________________ >Sablevm-developer mailing list >Sab...@li... >https://lists.sourceforge.net/lists/listinfo/sablevm-developer _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail |
From: Gunda D. <sab...@ho...> - 2002-12-11 15:21:01
|
>On Tue, Dec 10, 2002 at 03:17:33PM -0700, Gunda Domlur wrote: > > Bottom-line: I think it is better off to provide iflush with a second >size > > parameter and leave the implementation specfic for a particular > > architecture implementation. > > > > What say you ? > >Agreed. > So how difficult it is to change the iflush to include a second parameter (for indicating size) in sablevm ? Is it trivial or does it take lot of effort ? Later, -Gunda _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
From: Etienne M. G. <eti...@uq...> - 2002-12-11 15:46:34
|
Gunda Domlur wrote: > > So how difficult it is to change the iflush to include a second > parameter (for indicating size) in sablevm ? Is it trivial or does it > take lot of effort ? In SableVM: trivial In assembly: ... Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Gunda D. <sab...@ho...> - 2002-12-11 18:09:59
|
Thanks for the links. In files instructions.m4.c you have /* ---------------------------------------------------------------------- GOTO ---------------------------------------------------------------------- */ m4svm_instruction_head (GOTO, SVM_INTRP_FLAG_INLINEABLE, 2); pc = pc->addr; m4svm_instruction_tail (); Since GOTO changes the flow of control shouldn't that be flagged as _CONTAINS_BRANCH_OR_CALL ? There are a few others which looked suspicious. Am I missing something ? Thanks. -Gunda >On another note: If you want to play with inline-threading, please try >porting the folloowing interpreter to ARM: >http://www-sor.inria.fr/~piumarta/pldi98/vm.c > >In fact, you might want to read the paper: >http://www-sor.inria.fr/~piumarta/pldi98/ >http://www-sor.inria.fr/~piumarta/pldi98/paper.ps.gz > >If you can get it to work, it should give us the base framework to get >SableVM's inline-threaded engine to work on ARM. > >Have fun! > >Etienne > >-- >Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ >SableVM: http://www.sablevm.org/ >SableCC: http://www.sablecc.org/ > > >------------------------------------------------------- >This sf.net email is sponsored by: >With Great Power, Comes Great Responsibility >Learn to use your power at OSDN's High Performance Computing Channel >http://hpc.devchannel.org/ >_______________________________________________ >Sablevm-developer mailing list >Sab...@li... >https://lists.sourceforge.net/lists/listinfo/sablevm-developer _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
From: Etienne M. G. <eti...@uq...> - 2002-12-11 21:11:46
|
Gunda Domlur wrote: > Thanks for the links. > > In files instructions.m4.c you have > > /* > ---------------------------------------------------------------------- > GOTO > ---------------------------------------------------------------------- > */ > > m4svm_instruction_head (GOTO, SVM_INTRP_FLAG_INLINEABLE, 2); > > pc = pc->addr; > > m4svm_instruction_tail (); > > Since GOTO changes the flow of control shouldn't that be flagged as > _CONTAINS_BRANCH_OR_CALL ? There are a few others which looked suspicious. > > Am I missing something ? Yes (just a little). There's no need to flag GOTO (and other similar end-of-basic-block instructions) specially, as basic blocks are not computed based on this flag; they're computed based on the type of instruction. [Unlike the Piumarta algo/interpreter]. Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Etienne M. G. <eti...@uq...> - 2002-12-11 21:25:22
|
Gunda Domlur wrote: > > m4svm_instruction_head (GOTO, SVM_INTRP_FLAG_INLINEABLE, 2); > > pc = pc->addr; > > m4svm_instruction_tail (); > > Since GOTO changes the flow of control shouldn't that be flagged as > _CONTAINS_BRANCH_OR_CALL ? There are a few others which looked suspicious. Also... Note that the body : pc = pc->addr; does NOT include any "if/switch/while"..." branch statement, nor any function call. :-) Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Gunda D. <sab...@ho...> - 2002-12-11 18:57:41
|
Sorry, another question. In file constants.h you have /* interpreter flags */ #define SVM_INTRP_FLAG_UNUSED 0 #define SVM_INTRP_FLAG_SPECIAL 1 #define SVM_INTRP_FLAG_INLINEABLE 2 #define SVM_INTRP_FLAG_CONTAINS_BRANCH_OR_CALL 3 The meaning of _UNUSED, _INLINEABLE and _BRANCH_OR_CALL seems obvious. What is _SPECIAL ? Is it inlinebale or not ? Thanks. -Gunda >From: "Etienne M. Gagnon" <eti...@uq...> >To: Gunda Domlur <sab...@ho...> >CC: sab...@li... >Subject: Re: [Sablevm-developer] Flushing strategy .... >Date: Tue, 10 Dec 2002 22:43:35 -0500 > >On Tue, Dec 10, 2002 at 03:17:33PM -0700, Gunda Domlur wrote: > > Bottom-line: I think it is better off to provide iflush with a second >size > > parameter and leave the implementation specfic for a particular > > architecture implementation. > > > > What say you ? > >Agreed. > > >On another note: If you want to play with inline-threading, please try >porting the folloowing interpreter to ARM: >http://www-sor.inria.fr/~piumarta/pldi98/vm.c > >In fact, you might want to read the paper: >http://www-sor.inria.fr/~piumarta/pldi98/ >http://www-sor.inria.fr/~piumarta/pldi98/paper.ps.gz > >If you can get it to work, it should give us the base framework to get >SableVM's inline-threaded engine to work on ARM. > >Have fun! > >Etienne > >-- >Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ >SableVM: http://www.sablevm.org/ >SableCC: http://www.sablecc.org/ > > >------------------------------------------------------- >This sf.net email is sponsored by: >With Great Power, Comes Great Responsibility >Learn to use your power at OSDN's High Performance Computing Channel >http://hpc.devchannel.org/ >_______________________________________________ >Sablevm-developer mailing list >Sab...@li... >https://lists.sourceforge.net/lists/listinfo/sablevm-developer _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
From: Etienne M. G. <eti...@uq...> - 2002-12-11 21:22:49
|
Gunda Domlur wrote: > The meaning of _UNUSED, _INLINEABLE and _BRANCH_OR_CALL seems obvious. > What is _SPECIAL ? Is it inlinebale or not ? SPECIAL instructions are *special* instructions that do not participate in inline-threading. They are instructions like the special PREPARE_METHOD which is a handler used to lazily prepare a method, etc. This sould become clearer once you have read chapter 2 of my thesis. Among other special instructions are "slow preparation" instructions [e.g. the version of GETSTATIC which does class initialization if necessary]. Etienne > > Thanks. > -Gunda > > > > >> From: "Etienne M. Gagnon" <eti...@uq...> >> To: Gunda Domlur <sab...@ho...> >> CC: sab...@li... >> Subject: Re: [Sablevm-developer] Flushing strategy .... >> Date: Tue, 10 Dec 2002 22:43:35 -0500 >> >> On Tue, Dec 10, 2002 at 03:17:33PM -0700, Gunda Domlur wrote: >> > Bottom-line: I think it is better off to provide iflush with a >> second size >> > parameter and leave the implementation specfic for a particular >> > architecture implementation. >> > >> > What say you ? >> >> Agreed. >> >> >> On another note: If you want to play with inline-threading, please try >> porting the folloowing interpreter to ARM: >> http://www-sor.inria.fr/~piumarta/pldi98/vm.c >> >> In fact, you might want to read the paper: >> http://www-sor.inria.fr/~piumarta/pldi98/ >> http://www-sor.inria.fr/~piumarta/pldi98/paper.ps.gz >> >> If you can get it to work, it should give us the base framework to get >> SableVM's inline-threaded engine to work on ARM. >> >> Have fun! >> >> Etienne >> >> -- >> Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ >> SableVM: http://www.sablevm.org/ >> SableCC: http://www.sablecc.org/ >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: >> With Great Power, Comes Great Responsibility >> Learn to use your power at OSDN's High Performance Computing Channel >> http://hpc.devchannel.org/ >> _______________________________________________ >> Sablevm-developer mailing list >> Sab...@li... >> https://lists.sourceforge.net/lists/listinfo/sablevm-developer > > > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > . > -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Gunda D. <sab...@ho...> - 2002-12-11 23:29:39
|
pc=pc->addr is a branch right ? (an indirect one though). Maybe this is a terminology problem, but I thought if a processor changes execution path it is generally considered a branch (either due to a br instruction or due to moving a value directly into the pc). Where can I get hold of Chapter 2 of your thesis ? Thanks. -Gunda >From: "Etienne M. Gagnon" <eti...@uq...> >To: Gunda Domlur <sab...@ho...> >CC: sab...@li... >Subject: Re: [Sablevm-developer] Flushing strategy .... >Date: Wed, 11 Dec 2002 16:17:43 -0500 > >Gunda Domlur wrote: >> >> m4svm_instruction_head (GOTO, SVM_INTRP_FLAG_INLINEABLE, 2); >> >> pc = pc->addr; >> >> m4svm_instruction_tail (); >> >>Since GOTO changes the flow of control shouldn't that be flagged as >>_CONTAINS_BRANCH_OR_CALL ? There are a few others which looked suspicious. > >Also... Note that the body : > > pc = pc->addr; > >does NOT include any "if/switch/while"..." branch statement, nor any >function call. :-) > >Etienne > >-- >Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ >SableVM: http://www.sablevm.org/ >SableCC: http://www.sablecc.org/ > > > >------------------------------------------------------- >This sf.net email is sponsored by: >With Great Power, Comes Great Responsibility Learn to use your power at >OSDN's High Performance Computing Channel >http://hpc.devchannel.org/ >_______________________________________________ >Sablevm-developer mailing list >Sab...@li... >https://lists.sourceforge.net/lists/listinfo/sablevm-developer _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
From: Etienne M. G. <eg...@j-...> - 2002-12-12 04:16:08
|
On Wed, Dec 11, 2002 at 04:28:35PM -0700, Gunda Domlur wrote: > pc=pc->addr is a branch right ? No. In C, it represents the assignment of a value retrieved from a field of a struct pointed-to by the local variable "pc" into the local variable "pc" itself. There is no branch in the machine code generated for this statement by any reasonible C compiler, such as GCC. Of course, one can guess that eventually this will cause the interpreter to execute some branch, but the statement itslef is free from any branch. [You have to read the code as "low-level" C code, not as "higher-level" Java bytecode]. > > Where can I get hold of Chapter 2 of your thesis ? Online, very soon. :-) [I won't be more precise, as the final decision of when is not in "my" hands, it's in McGill's hands.] Etienne -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Etienne M. G. <eti...@uq...> - 2002-12-11 15:46:52
|
Gunda Domlur wrote: > You had mentioned about running java programs which exercises all the > byte codes. Is there a benchmark/example java program which has the all > the byte-codes ? I don't know. You should give a look at the Mauve project (search "Mauve Java" on Google); maybe it has something. Etienne > > Thanks. > -Gunda > > > > > > >> From: "Etienne M. Gagnon" <eti...@uq...> >> To: Gunda Domlur <sab...@ho...> >> CC: sab...@li... >> Subject: Re: [Sablevm-developer] Flushing strategy .... >> Date: Tue, 10 Dec 2002 22:43:35 -0500 >> >> On Tue, Dec 10, 2002 at 03:17:33PM -0700, Gunda Domlur wrote: >> > Bottom-line: I think it is better off to provide iflush with a >> second size >> > parameter and leave the implementation specfic for a particular >> > architecture implementation. >> > >> > What say you ? >> >> Agreed. >> >> >> On another note: If you want to play with inline-threading, please try >> porting the folloowing interpreter to ARM: >> http://www-sor.inria.fr/~piumarta/pldi98/vm.c >> >> In fact, you might want to read the paper: >> http://www-sor.inria.fr/~piumarta/pldi98/ >> http://www-sor.inria.fr/~piumarta/pldi98/paper.ps.gz >> >> If you can get it to work, it should give us the base framework to get >> SableVM's inline-threaded engine to work on ARM. >> >> Have fun! >> >> Etienne >> >> -- >> Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ >> SableVM: http://www.sablevm.org/ >> SableCC: http://www.sablecc.org/ >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: >> With Great Power, Comes Great Responsibility >> Learn to use your power at OSDN's High Performance Computing Channel >> http://hpc.devchannel.org/ >> _______________________________________________ >> Sablevm-developer mailing list >> Sab...@li... >> https://lists.sourceforge.net/lists/listinfo/sablevm-developer > > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility Learn to use your power at > OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > 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/ |