Yes, very strange. The AVM2 spec says the jump instruction does not change the stack either (as you would expect).
On Wed, Oct 2, 2013 at 6:23 PM, Alex Harui <aha...@adobe.com> wrote: > When I look at the output, the sequence of ABC instructions generated by > MXMLC should be: > > Constructprop > Coerce_a > Jump > SetProperty > > And for Falcon > > ConstructProp > Jump > Coerce_a > SetProperty > > In x86 asm, a jump only moves the IP and doesn't change anything else. But > for some reason, AIR (and not FlashPlayer) is sensitive to that > difference. Very strange bug in AIR, IMO. Anyway, I do have Falcon > generating the coerce_a where MXMLC outputs it. > > On 10/2/13 3:13 PM, "Darrell Loverin" <darrell.love...@gmail.com> wrote: > > >Nice job figuring this out! Does your change now generate the coerce_a > >code in the same positions as the MXML compiler? The only difference I > >saw in byte code with respect to coerce_a was a "jump L1" instruction > >after (Falcon) a coerce_a instead before (mxmlc). > > > >mxmlc > >>>>>> constructprop private:SomeClass (1) > >>>>>> coerce_a > >>>>>> jump L1 > > > >Falcon > >>>>>> constructprop private:SomeClass (1) > >>>>>> jump L1 > >>>>>> L0: findpropstrict private:SomeOtherClass > >>>>>> getlocal1 > >>>>>> constructprop private:SomeOtherClass (1) > >>>>>> L1: coerce_a > > > >Was the "jump L1" instruction before the coerce_a the issue? > > > > > >-Darrell > > > >On Oct 2, 2013, at 4:24 PM, Alex Harui <aha...@adobe.com> wrote: > > > >> The reducer method now calls > >>getAncestorOfType(IBinaryOperatorNode.class) > >> and then checks if the operator is OoperatorType.ASSIGNMENT and further > >> that the left node is a DynamicAccessNodel > >> > >> I think just checking parent isn't good enough for nested ternary > >> expressions. > >> > >> Coerce is being called in a few other reduction methods that may take > >>care > >> of the other scenarios you mention. If not, we'll add calls as needed. > >> > >> -Alex > >> > >> > >> On 10/2/13 1:18 PM, "Gordon Smith" <gosm...@adobe.com> wrote: > >> > >>> In the reducer method for the ternary expression, how do you know > >>>whether > >>> it going to be assigned to a foo[bar] expression? Do you look at the > >>> parent node of the ternary expression? I have a feeling that that isn't > >>> how JBurg is supposed to be used, but maybe you can get away with it. > >>>You > >>> should probably have a different JBurg pattern and reduce method just > >>>for > >>> this case. > >>> > >>> I'm also not convinced this covers all the relevant situations where a > >>> coerce_a might be necessary. For example, suppose that instead of being > >>> assigned to a left-hand-side of type *, the ternary expression is being > >>> passed as a argument to a function that has a type * parameter. That > >>> might also need a coerce_a. > >>> > >>> I'd put a comment in the code that this is questionable. But if it gets > >>> your app further towards working, it's good. > >>> > >>> - Gordon > >>> > >>> -----Original Message----- > >>> From: Alex Harui [mailto:aha...@adobe.com] > >>> Sent: Wednesday, October 02, 2013 11:52 AM > >>> To: dev@flex.apache.org > >>> Subject: Re: [FALCON] using coerce_a > >>> > >>> The code only thinks about coercing if there is a bracket [] node. It > >>> gets the type of the left hand side via resolveType and compares the > >>> resolveType of the clause node and calls coerce if it doesn't match. > >>>So > >>> your example won't have a coerce_a in the ABC. > >>> > >>> -Alex > >>> > >>> On 10/2/13 11:19 AM, "Gordon Smith" <gosm...@adobe.com> wrote: > >>> > >>>> Does that work for ternary expressions and left-hand-sides with other > >>>> types, such as > >>>> > >>>> var i:int = true ? 1 : 2; > >>>> > >>>> ? > >>>> > >>>> - Gordon > >>>> > >>>> On 10/2/13 11:01 AM, "Alex Harui" <aha...@adobe.com> wrote: > >>>> > >>>>> Update: Changing Falcon to generate the coerce_a in the ternary > >>>>> clauses allowed it to work for AIR. The code change is only in > >>>>> ternary expression reduction so I think it won't hurt performance too > >>>>> much. > >>>>> > >>>>> -Alex > >>>>> > >>>>> On 10/1/13 10:09 PM, "Alex Harui" <aha...@adobe.com> wrote: > >>>>> > >>>>>> So, I added code to add the coerce_a and it did not help. I get the > >>>>>> same corrupted output. > >>>>>> > >>>>>> Here is the AS: > >>>>>> package { > >>>>>> public class foo { > >>>>>> private var dict:Dictionary = new Dictionary(); public function > >>>>>> addInstance(instance:ISomeInterface):void > >>>>>> { > >>>>>> dict[instance.uid] = (instance.someBoolean ? new > >>>>>>SomeClass(instance) : > >>>>>> new SomeOtherClass(instance)); > >>>>>> ... > >>>>>> } > >>>>>> } > >>>>>> > >>>>>> //internal class > >>>>>> class SomeClass{ > >>>>>> public function SomeClass(instance:ISomeInterface) > >>>>>> { > >>>>>> } > >>>>>> //internal class > >>>>>> class SomeOtherClass{ > >>>>>> public function SomeOtherClass(instance:ISomeInterface) > >>>>>> { > >>>>>> } > >>>>>> > >>>>>> > >>>>>> > >>>>>> Here is the ABC from MXMLC that works: > >>>>>> > >>>>>> > >>>>>> getlocal0 > >>>>>> pushscope > >>>>>> getlocal0 > >>>>>> getproperty private:dict > >>>>>> getlocal1 > >>>>>> getproperty ISomeInterface:uid > >>>>>> getlocal1 > >>>>>> getproperty ISomeInterface:someBoolean > >>>>>> iffalse L0 > >>>>>> > >>>>>> findpropstrict private:SomeClass > >>>>>> getlocal1 > >>>>>> constructprop private:SomeClass (1) > >>>>>> coerce_a > >>>>>> jump L1 > >>>>>> L0: findpropstrict private:SomeOtherClass > >>>>>> getlocal1 > >>>>>> constructprop private:SomeOtherClass (1) > >>>>>> coerce_a > >>>>>> L1: setproperty > >>>>>> private,private,,http://adobe.com/AS3/2006/builtin:null > >>>>>> > >>>>>> Here is the ABC from Falcon that doesn't work: > >>>>>> > >>>>>> getlocal0 > >>>>>> pushscope > >>>>>> getlex private:dict > >>>>>> getlocal1 > >>>>>> getproperty ISomeInterface:uid > >>>>>> getlocal1 > >>>>>> getproperty ISomeInterface:someBoolean > >>>>>> iffalse L0 > >>>>>> > >>>>>> findpropstrict private:SomeClass > >>>>>> getlocal1 > >>>>>> constructprop private:SomeClass (1) > >>>>>> jump L1 > >>>>>> L0: findpropstrict private:SomeOtherClass > >>>>>> getlocal1 > >>>>>> constructprop private:SomeOtherClass (1) > >>>>>> L1: coerce_a > >>>>>> setproperty > >>>>>> > >>>>>> > >>>>>>private,flash.events:EventDispatcher,Object,private,, > http://adobe.com > >>>>>> /A > >>>>>> S > >>>>>> 3 > >>>>>> / > >>>>>> 2006/builtin:null > >>>>>> > >>>>>> I'm beginning to think this is an AIR bug since the Falcon ABC runs > >>>>>> fine on Flash. I'm going to try to replicate the MXMLC's placement > >>>>>> of coerce_a and see if that gets the code to work in AIR. > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> -Alex > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 9/30/13 10:50 PM, "Alex Harui" <aha...@adobe.com> wrote: > >>>>>> > >>>>>>> There's no error, the Dictionary value appears be a Number instead > >>>>>>> of an instance. > >>>>>>> > >>>>>>> Are you sure that Vector access doesn't come through this code? I > >>>>>>> think I'll start by testing only for ANY_TYPE and adding a coerce_a > >>>>>>> instead of calling coerce() which would also coerce to any > >>>>>>> destination type. > >>>>>>> > >>>>>>> Thanks for the advice, > >>>>>>> -Alex > >>>>>>> ________________________________________ > >>>>>>> From: Darrell Loverin [darrell.love...@gmail.com] > >>>>>>> Sent: Monday, September 30, 2013 6:11 PM > >>>>>>> To: dev@flex.apache.org > >>>>>>> Subject: Re: [FALCON] using coerce_a > >>>>>>> > >>>>>>> I generally agree. I don't think I'd try to do anything inside the > >>>>>>> ternary expression reduce. > >>>>>>> > >>>>>>> I'd look at the coerce() method in ABCGeneratingReducer to try to > >>>>>>> figure out why it is not being called. > >>>>>>> > >>>>>>> > >>>>>>> Question for Alex. What error are you seeing on AIR? A TypeError, a > >>>>>>> ReferenceError? > >>>>>>> > >>>>>>> -Darrell > >>>>>>> > >>>>>>> > >>>>>>> On Mon, Sep 30, 2013 at 8:00 PM, Gordon Smith <gosm...@adobe.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Thanks Darrell. > >>>>>>>> > >>>>>>>> Here are my answers to Alex's questions: > >>>>>>>> > >>>>>>>>> Should a complex assignment statement like the above know about > >>>>>>>>> the > >>>>>>>> destination type as the clauses of the ternary statement are being > >>>>>>>> reduced? > >>>>>>>> > >>>>>>>> No. > >>>>>>>> > >>>>>>>>> Is it safe to add a coerce_a before an assignment to a > >>>>>>>>>Dictionary? > >>>>>>>> > >>>>>>>> Yes. > >>>>>>>> > >>>>>>>>> If so, what would be the recommended way to determine the > >>>>>>>> assignment > >>>>>>>> is > >>>>>>>> to a Dictionary? > >>>>>>>> > >>>>>>>> The compile-time type of foo[bar], where foo has any type (not > >>>>>>>> just Dictionary), is type *. So I think it is OK to codegen > >>>>>>>> coerce_a before assignment to any foo[bar] expression. > >>>>>>>> > >>>>>>>> Darrell, do you agree or disagree? > >>>>>>>> > >>>>>>>> - Gordon > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Darrell Loverin [mailto:darrell.love...@gmail.com] > >>>>>>>> Sent: Monday, September 30, 2013 3:41 PM > >>>>>>>> To: dev@flex.apache.org > >>>>>>>> Subject: Re: [FALCON] using coerce_a > >>>>>>>> > >>>>>>>> coerce_a Operation > >>>>>>>> > >>>>>>>> Coerce a value to the any type. > >>>>>>>> > >>>>>>>> Format > >>>>>>>> > >>>>>>>> coerce_a > >>>>>>>> > >>>>>>>> Forms > >>>>>>>> > >>>>>>>> Stack > >>>>>>>> > >>>>>>>> ..., value => ..., value Description > >>>>>>>> > >>>>>>>> Indicates to the verifier that the value on the stack is of the > >>>>>>>> any type (*). Does nothing to value. > >>>>>>>> > >>>>>>>> > >>>>>>>> On Mon, Sep 30, 2013 at 6:03 PM, Gordon Smith <gosm...@adobe.com> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Can you remind me what the "a" in coerce_a means? > >>>>>>>>> > >>>>>>>>> - Gordon > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Alex Harui [mailto:aha...@adobe.com] > >>>>>>>>> Sent: Monday, September 30, 2013 2:43 PM > >>>>>>>>> To: dev@flex.apache.org > >>>>>>>>> Subject: [FALCON] using coerce_a > >>>>>>>>> > >>>>>>>>> Gordon, Darrell (mostly) > >>>>>>>>> > >>>>>>>>> My latest problem appears to be in assigning to a Dictionary. > >>>>>>>>> For > >>>>>>>> the > >>>>>>>>> following code: > >>>>>>>>> > >>>>>>>>> var dict:Dictionary = new Dictionary(); Var i:int; Dict["foo"] = > >>>>>>>>> (i > >>>>>>>> == > >>>>>>>>> 0 ? new SomeClass() : new SomeOtherClass()); > >>>>>>>>> > >>>>>>>>> MXMLC generates a coerce_a after the constructProp for both > >>>>>>>> SomeClass > >>>>>>>>> and SomeOtherClass. > >>>>>>>>> For some reason, FlashPlayer doesn't care if the coerce_a is > >>>>>>>> missing, > >>>>>>>>> but AIR seems to. > >>>>>>>>> > >>>>>>>>> The question is, should a complex assignment statement like the > >>>>>>>> above > >>>>>>>>> know about the destination type as the clauses of the ternary > >>>>>>>>> statement are being reduced? And if so, how would we get that > >>>>>>>> knowledge > >>>>>>>> into the reducer. > >>>>>>>>> > >>>>>>>>> Alternatively, is it safe to add a coerce_a before an assignment > >>>>>>>>> to > >>>>>>>> a > >>>>>>>>> Dictionary? If so, what would be the recommended way to > >>>>>>>>> determine > >>>>>>>> the > >>>>>>>>> assignment is to a Dictionary? > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> -Alex > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > >
