-
1. Re: Could not match memory address. Inline asm failure!
zazzo9 Apr 7, 2009 12:26 PM (in response to XIXs)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!
XIXs Apr 7, 2009 10:27 PM (in response to zazzo9)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
-
3. Re: Could not match memory address. Inline asm failure!
zazzo9 Apr 9, 2009 3:59 AM (in response to XIXs)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!
XIXs Apr 9, 2009 7:50 AM (in response to zazzo9)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.

