|
|
"Christopher James Huff" <chr### [at] maccom> wrote:
> > No ... this is not what I meant ... I mean, that the prog, can modify itself
> > in memory, to speedup execution ...
>
> Well, what's stopping you? You would have to interface through the
> ordinary POV-Script and write it to the disk in order to load it again,
> but the result would be the same: dynamically generated code being
> loaded into memory and executed. Just a bit roundabout, and a large
> chunk of the required code would have to be written in POV-Script
> instead of being done by the function engine. It would also be very
> slow...
nope... that's not what I meant...
Consider this pseudo-code
-----------------------------------
A=SomeExpression(Input)
repeat
DoSomething()
if (A=SomeValue)
FarCall SubRoutine1
else
NearCall SubRoutine2
endif
DoSomethingElse()
until (End)
------------------------------------
as you can see: the if-instruction is executed very often...
In Self-modifying-ASM-code one could write:
------------------------------------
A=SomeExpression(Input)
if (A=SomeValue)
[ChangeHere]=OpCodeOf(FarCall SubRoutine1)
else
[ChangeHere]=OpCodeOf(NearCall SubRoutine2)
endif
repeat
DoSomething()
:ChangeHere
noop
noop
noop
noop
DoSomethingElse()
until (End)
------------------------------------
I once had a chance, to speed up the Bresenham by a factor of 3 by a similar method.
The thing is that you can decide at runtime, which opcodes get executed, depending
on some runtime values
As there are(were) different opcodes used for a near-jump (target-address, beein in
the same codesegment) and a far-jump (jump to anywhere in memory) there was no easy
chance, to work only with pointers, and only change these...
Of course, my last lines applied to my active assembler time, when I did some
x86-Realmode ASM ....
I hope you got the idea ...
Post a reply to this message
|
|