On 2 Dec 2005, at 06:09, Asger Alstrup wrote:
Oliver Steele wrote:
The platform currently supports inline assembly (inside the
#pragma), but I don't know whether this will survive the compiler
port to Java.
Is there an example somewhere for how to do this?
If you grep through the sources of the LFC, you will see
if ($flasm) {
... assembly ...
} else {
... javascript ...
}
blocks (which are vestigal -- as Oliver said, they were written for
the swf5 player). They should give you an inkling of what you need
to write. These blocks were written by using `flasm` to decompile
existing functions and then rewriting the assembly by hand. The
point of the if/else is to retain the original equivalent Javascript
for alternate targets.
To enable compilation of $flasm blocks they would have to be in a
block with `#pragma "flashCompilerCompatibility=true". (This is a
poorly named flag because it hardly means flash compiler
compatibility any more -- it simply enables a number of internal
features and is true by default for the compilation of the LFC.) For
example, you could say:
function myFlasmFun () {
#pragma "flashCompilerCompatibility=true"
if ($flasm) {
... assembly ...
} else {
... javascript ...
}
}
There's one big catch with trying to exploit this: the compiler does
not generate `function2` for any function that has internal $flasm
blocks (because there is no syntax or mechanism for assigning
parameters to specific register numbers), so it simply generates
`function` and passes $flasm directly through to the assembler.
[...]
My experience is with Flash 8. Although the registers are much
faster than variables, the stack is even faster yet. In our
applications, we really want to push the edge of what Flash can do
for us, so eventhough we unroll loops manually and try to optimise
as best we can at the JavaScript level, we still find that it is
not fast enough. Assembler is the answer for these inner-most loops.
That's interesting to know. That is an optimization the compiler
does not attempt yet.
Another question concerns Flash 8.5: Given the anedoctal evidence
about the improved performance of Flash 8.5, this would be an
alternative solution for us in terms of performance issues.
There is a wiki-page about this where you provide some tools for
starting the reverse engineering of this. Is this something you
will allocate resources to? I am considering to find someone to
work on it as well...
Very much so! We are actively working on re-modularizing the
compiler chain to permit alternate target runtimes. This seems like
the better direction to follow since it will improve the efficiency
of all code.
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
