4 Replies Latest reply: Apr 9, 2009 7:50 AM by XIXs RSS

    Could not match memory address. Inline asm failure!

      Hi,

       

      Any ideas on what might be triggering the above error at link time, not compile time?

       

      I'm currently suspecting it is just a size thing, my initial tests built fine but when I tried building something much bigger I get this error.

       

      I've tried linking various parts of the project files rather than all of them and the error kicks in seemingly randomly depending mostly on how much I ask it to link rather than which files I ask it to link which is what makes me think it might be a size thing.

       

      Are there any hard code size limits using alchemy?

       

      Or anyway to get more information about what is going wrong, maybe something I'm building is actually using some inline asm somewhere (its possible but I did try hard to stop such a thing happening) or is that a red herring?

       

      I'm using ubuntu to build on.

       

      Kriss

        • 1. Re: Could not match memory address. Inline asm failure!
          zazzo9 Community Member

          Something you are building is using inline asm somewhere.  Specificially, it is using gnu extended asm with a memory operand constraint.  Changing the constraint to a register operand constraint ('r' instead of 'm') should get the asm compiling -- but, of course, you probably don't want it there at all.

           

          The error kicks in seemingly randomly because the asm only survives to the final link stage if it is actually called.  Hence, you could theoretically identify it by commenting and uncommenting pieces of code in subsequently smaller blocks, doing a sort of binary search.

           

          What are you trying to build?

          • 2. Re: Could not match memory address. Inline asm failure!
            Community Member

            Thank you

             

            I managed to catch it by adding

             

            -Dasm=broken -D_asm=broken -D__asm=broken -D__asm__=broken

             

            to the compile flags to trip it up at compile time

             

            I'm seeing if I can convince opengl, well mesa, to build in software mode, it seems to be working but the link time is a bit of a killer. Chugs away for 10 minutes eating up a gig of ram in the process. Makes testing anything on the c side rather long winded. My fault for only having a developer machine rather than a gamer machine I supose.

             

            I'm hoping I can reuse some other code I have and render sprite sheets from 3d avatars client side. I'm not expecting much speed from doing this and I'm certainly not thinking realtime.

             

            Switching on optimizations seemed to break it, which means its running even slower than it should, sadly the link time + compile time makes testing all of this rather prohibitive for me.

             

            Anyway behold the power of flash-alchemy-opengl, a rotating cube in only 1.5meg of swf, ho ho ho

             

            http://data.wetgenes.com/tmp/mesatest.swf

             

             

            I'll try and clean this build process up so it might be of use to other people, its been through a few iterations trying to get things to work and of course most of it is untested, all I know is it draws cubes.

             

             

            Cheers,

             

            Kriss

             

            http://www.wetgenes.com/

            • 3. Re: Could not match memory address. Inline asm failure!
              zazzo9 Community Member

              That is incredibly sweet.  I noticed no delays (loading, displaying) on my gaming computer over here.

               

              If the bulk of the compiling slowdown is due to adobe's llc, you might be stuck -- but if it's due to one of the llvm-gcc processes there are probably things you can do to speed it up.

               

              I haven't looked into them much, but I noticed that the alchemy library comes with a number of 'vgl' functions already defined -- if this is some kind of simulation of HP's "virtual gl" it could be some help -- don't really know.  You can see all of the embedded functionality by running llvm-dis on ${ALCHEMY_HOME}/avm2-libc/lib/avm2-libc.l.bc

               

              I repeat, opengl in a browser window is incredibly sweet.  It's too bad for the compile time.  It'd be cool to see the source.

              • 4. Re: Could not match memory address. Inline asm failure!
                Community Member

                everything I have should be checked into my svn at

                 

                https://trac.xixs.com/wet/cgi-bin/trac.cgi/browser/swf/alchemy

                 

                and you should be able to svn checkout from here with a login of anonymous and an empty password

                 

                https://svn.xixs.com/wet/swf/alchemy

                 

                I'm still trying to clean things up since I've been hacking around to see what works, I want to build everything using cmake but there are some issues with that, possibly using the wrong AR now that I think about it, but for now something like the following should produce a working swf

                 

                from the checked out svn folder and with flex/alchemy setup and alc-on

                 

                cd swc/mesa

                make

                cd ../test

                make

                 

                -- and I've just remembered that this bit is under windows, sorry its just a simple build of the as3 code linking to the .swc generated above looking at the .bat should be obvious what it has to do anyway I'll go quickly check in an untested .sh version so a ./bake.sh should work

                 

                cd ../../as3/test

                ./bake.sh

                 

                that should get a working test.swf, feel free to try

                 

                Some java code running at the end of link is the main build issue for me now, I tried another test with some more complicated geometry built into the test.c instead of a cube but that was enough to break things by running out of memory at link time.

                 

                Its looking promising but I'm going to need much more c code built into the swc before it can do what I want so the building issues are a bit worrying.

                 

                If I can convince alchemy to be a little bit less resource hungry that would be sweet.

                 

                Hmm, maybe it is possible to have multiple .swc builds that call into each others c code that would probably help if things could be built separately. With some source hacks of course.

                 

                Still next step for me will be to tidy things up more so I can run the same code natively and setup the rendering with my avatar stuff and then try and push that all over to alchemy and control it in flash.