Jan Walzer wrote in message <3ca7838e@news.povray.org>...
>Ahhh ... nice ...
>
>Thats what I wanted to read ...
>
>Seems very complete and useful ...
>
>Will this get included into the official doc ? ...
>I would much apreciate this ...

Did you notice that disclaimer at the end of the message?

> OF COURSE THIS IS ALL SUBJECT TO COMPLETE CHANGE AND REDESIGN IN CURRENT
AND
> FUTURE VERSIONS OF POV-RAY!

It won't make the official documentation.

--
Mark

Post a reply to this message

In article <3ca7cb87@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   If the code being executed is modified, it invalidates the pipelines and
> perhaps even the code in the cache

There is a far more severe problem here:  All processor architectures
developed in the past 20 years (mostly RISC or VLIW ones of course) have
independent data and instruction caches as well as independent data and
instruction MMUs.  Consequently the modified *data* is in the data cache and
the processors has no idea it is supposed to be *code*.  In fact it cannot
know what it is.  The only reliable means the programmer has to be sure it
will be executed is to *flush* the data and instruction cache.

Intel, on the other hand, maintained a kind of internal common bus at least up
to the Pentium Pro.  That is, instruction and data cache share a common
interface to the actual bus interface.  On other architectures the bus
interface provides two separate busses - one to the data and one to the
instruction cache.  What this effectively implies is that until Intel somehow
changed the design (I have no idea how current P4s detect self-modifying code,
if they can do so efficiently at all!), the speed and efficiency of the
instruction cache was reduced.

>   Of course self-modification is ok if you first modify the code to be
> executed, and then this code is executed for a long period of time.

And it will flush the caches accordingly.  The same needs to be done for
just-in-time compilers.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3ca792d1@news.povray.org> , "Jan Walzer" <jan### [at] lzernet> wrote:

> Hey ... for my studies, I had the chance to "port" this x86-code to
> MIPS-ASM ... It was perfectly possible, meaning, it worked...
> ... I couldn't messure any speedup, as it run on a software-MIPS-simulater,
> called "SPIM" ... if it was useful, is another chapter, but at least it was
> fun (for me, at least) ...

SPIM is indeed very neat except that its programmers made a too big fuss about
byte order and got the memory view all wrong :-(

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 1 Apr 2002 00:22:09 +0200, "Rune" <run### [at] mobilixnetdk> wrote:
> Maybe you already knew this, but then, maybe you didn't, so...

Yes, I knew that as I said in rest of thread. 

ABX

Post a reply to this message

wrote:
> I wonder if this is optimized if functions evaluator:

I want to keep all issues about such optimizations in one thread if possible so
I ask next question here again:

Let's cosider such code:

#local F1=function{...};
#local F2=function{F1(x,y,z)};
#local F3=function{F2(x,y,z)};
#local F4=function{F3(x,y,z)};

After parsing all F1, F2, F3, F4 point to the same function or waste time for
call ancestors ? Mainly I ask for case of macro and/or array creation, for
example:

#local F1=function{x};
#local F2=function{y};

#macro Operation( Function )
  /* do something with Function */
#end

#macro Test(Array)
  #local Size=dimension_size(Array,1);
  #local C=0;
  #while (C<Size)
    Operation( function{ Array[C](x,y,z) } )
    #local C=C+1;
  #end
#end

Test( array[2]{ function{F1(x,y,z)} , function{F2(x,y,z)} } )

ABX

Post a reply to this message