Re: Fwd: Re: More precise values in Analyzer

  Maybe I don't understand your issue completely, but this and method 
param values are easy. Normally you can tell them by variable slot number.
  Also, I was referring to the SourceInterpreter, which records exactly 
where values came from. Not the best javadoc there, but look at the 
users guide book for more details and examples.
  I guess there is a bit of gap, i.e. we don't have an Interpreter that 
provides both the type and source at the same time.

  regards,
  Eugene


Joshua Warner wrote:
> I accidentally replied to you directly, instead of the mailing list...
>
> ---------- Forwarded message ----------
> From: *Joshua Warner* <[email protected] 
> <mailto:[email protected]>>
> Date: Thu, Jul 15, 2010 at 2:16 PM
> Subject: Re: [asm] Re: More precise values in Analyzer
> To: Eugene Kuleshov <[email protected] <mailto:[email protected]>>
>
>
> Eugene,
>
> Perhaps I don't understand what you mean, but the only information 
> passed to the Interpreter.newValue method is the Type of the requested 
> value.
>
> The problem I am having is more related to values that aren't produced 
> by opcodes / instructions - such as the parameters in the local 
> variable slots and the "this" pointer.  I need to be able to 
> distinguish when a Value generated through newValue() is a parameter, 
> "this" pointer or uninitialized value.
>
> Sincerely,
>
> Joshua
>
>
> On Thu, Jul 15, 2010 at 2:05 PM, Eugene Kuleshov <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Joshua,
>
>      Isn't value source can be derived from the opcode type that
>     produced it?
>
>      regards,
>      Eugene
>
>
>     On Thu, Jul 15, 2010 at 3:56 PM,  <[email protected]
>     <mailto:[email protected]>> wrote:
>     >
>     > Hi,
>     >
>     > Im trying to use ASM in a Java-to-LLVM translator project.  In
>     short, I'm using
>     > the Analyzer and a custom version of Value to (attempt to)
>     extract a SSA form
>     > of the Java bytecode.
>     >
>     > The problem I am having is that some of the origins of the
>     values are not
>     > precise enough.  For instance, at present, it seems impossible
>     to track where
>     > some of the values originally came from - Analyzer.analyze just
>     calls
>     > Interpreter.newValue(...) for uninitialized values, parameters,
>     the this
>     > reference, etc.
>     >
>     > What do you recommend?
>     >
>     > Would I be able to get a patch through that gives the
>     Interpreter room to
>     > distinguish between these?  I propose adding
>     Interpreter.newParameter(int
>     > index, Type type), Interpreter.newReturnValue(Type type),
>     > Interpreter.newThisReference(Type type), and
>     Interpreter.newUninitialized().
>     >
>     > FYI, I am using the stable 3.3 version - but the nightly SVN
>     seems to have the
>     > same problem.
>     >
>     > Sincerely,
>     >
>     > Joshua Warner
>     >
>     >
>     > --
>     > You receive this message as a subscriber of the [email protected]
>     <mailto:[email protected]> mailing list.
>     > To unsubscribe: mailto:[email protected]
>     <mailto:[email protected]>
>     > For general help: mailto:[email protected]
>     <mailto:[email protected]>?subject=help
>     > OW2 mailing lists service home page: http://www.ow2.org/wws
>     >
>     >
>
>
>     --
>     You receive this message as a subscriber of the [email protected]
>     <mailto:[email protected]> mailing list.
>     To unsubscribe: mailto:[email protected]
>     <mailto:[email protected]>
>     For general help: mailto:[email protected]
>     <mailto:[email protected]>?subject=help
>     OW2 mailing lists service home page: http://www.ow2.org/wws
>
>
>

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws