It looks as if the memory is protected anyway, according to:
http://ncannasse.fr/blog/adobe_alchemy ...
"As a reminder, the Alchemy pipeline is the following : .c file *->*
LLVM intermediate bytecode *->* AVM2 bytecode
However, in general, doing so reduces a lot the performances. Especially
since the abstraction level of the AVM2 bytecode is a lot higher than
the one of the LLVM bytecode, it means that all arbitrary operations
such as pointer and memory manipulation which are done in C must be
/wrapped/ by using the memory-safe mechanisms which are available in
AVM2, such as a |flash.utils.ByteArray| to represent the memory data."
If the AVM2 (Adobe ActionScript™ Virtual Machine 2) does allow
unprotected access, then malicious code could get through via Alchemy or
haXe.
I can't believe that to be true.
Anyway, why would Adobe build it in and not use it?
Strange.
John
Glen Pike wrote:
sandbox? Am guessing direct memory access maybe disallowed because
people could try to exploit buffer overflows...
John McCormack wrote:
Thank you for that, it was very interesting.
It was certainly faster for those operations.
< opcodes which aren't available in AS3
It doesn't seem possible that those opcodes, for direct memory
access, are not used by Adobe.
Why would that be?
John
Meinte van't Kruis wrote:
Joa Ebert's apparat can be found here:
http://blog.joa-ebert.com/2009/08/11/apparat-is-now-open-source/
<http://blog.joa-ebert.com/2009/08/11/apparat-is-now-open-source/>As
far as
Cannassa is concerned, he is best known for Haxe, which uses alchemy
opcodes
here and
there(with his flash.memory implementation, but I'm no haxe expert),
here is
the url:
http://ncannasse.fr/blog/virtual_memory_api
Offcourse it all still runs in the same Flash sandbox, I believe the
performance gains are basically due to
the fact that alchemy compiled code can do memory access faster by
using
opcodes which arent
available in AS3 (don't ask me why). Anyway, I'm no expert, but a
bit of it
is explained here:
http://ncannasse.fr/blog/adobe_alchemy
On Wed, Jan 6, 2010 at 12:19 PM, John McCormack
<j...@easypeasy.co.uk>wrote:
Meinte van't Kruis wrote:
Seeing the whole apparat project of Joa Ebert or the stuff Nicolas
Cannasse
Are their projects available to see?
implementing some alchemy to speed things up.
As far as I understand it, the C++ code is still converted into
Flash's
byte codes, so any performance gain must have been from the
algorithms in
the C++ code.
How much difference did it make?
John
On Tue, Jan 5, 2010 at 4:07 PM, Paul Andrews <p...@ipauland.com>
wrote:
Meinte van't Kruis wrote:
Actually, I think performance should be on top of the priority
list for
any
Flash developer.
Unresponsive flash apps are the number one irritation imho.
LOL, I have yet to write one and I have yet to use any techniques
from my
assembler or C++ days. In most cases Flash provides more than
adequate
responsiveness with very little special care.
The top of the priority list is a user experience that makes the
client
happy and performance and responsiveness has yet to be a deciding
issue.
The most challenging responsiveness issue I have had has been
parsing
large
text files for data (several megabytes in size) using AS2 while
keeping a
visualisation animating smoothly and preventing script time-outs.
It was
very much the rare exception.
I realise that for some people manipulating large numbers of
animated
clips
or sprites, performance could be an issue, but I think such
applications
of
flash aren't the mainstream.
Paul
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
