Script optimization

Most compilers, even without optimization, only modify the stack pointer once for all the local variables required for a function's stack frame. Not only that, but most non-trivial functions will require SOME (at least temporary) value on the function's stack frame. So I disagree. Unless the compiler is a completely amateur one written overnight (and perhaps the LSL qualifier DOES qualify ) a local variable is not likely to result in any more instructions than the global variable.

Right. The point is that in ("purely" single-threaded environments, a global might only have to be accessed the first time it is read and/or the last time it is written in a function (oh, there's one more spot that doesn't apply to locals: where another function is called), not at every access or thread synchronization point. So in essence they CAN be about as efficient as local variables in a single-threaded environment.

As I understand it, most modern architectures do register-indexed (or possibly just stack-indexed depending on how specialized the processor) memory access just as quickly as direct access. Both only require one memory access, as opposed to true indirection (accessing memory referenced by memory rather than a register) which requires two accesses (though it is still often optimized to be faster than two full instructions to fetch and then read).

I didn't modify the stack pointer in that code sample, I modified R1.

R1 <- offset
R1 <- R1 + SP
R2 <- mem(R1)

Some instruction sets make part of that a single operation with complex addressing modes, but internally the CPU is performing the same operations. EG, for a classic CISC like the PDP-11, if the offset is small enough, you can do:

MOV @offset(sp),r2

But that code doesn't generally involve loading an offset as well as the stack. Even for a non-optimizing compiler: either the compiler is doing a straightforward stack based expression evaluator, or they're generating register code and keeping intermediate values in registers.

And, again, the LSL compiler performs NO optimization. You can verify that by examining indra.l, indra.y, lscript_tree.cpp, and so on in the open source client.

No optimization? Darn. Has anyone tested whether there's still a difference between:

integer index;
integer length = llGetListLength(myList);
for (index = 0; index < length; index++) {}

and

integer index;
for (index = 0; index < llGetListLength(myList); index++) {}

I was rather hoping to see some simple optimizations that cope with situations like this

/esc

Fully object-oriented languages don't just reserve stack space, they create the object.

Interpreted languages can work completely differently. For example, in Python, the variable is created and its name is added to the scope's dictionary.

Neither of these is a case of an amateur compiler, and there are more cases.

As I said above, it doesn't make sense to generalize. There are so many different possibilities.

"Languages" don't do any of that... compilers/interpreters do.
The nightmare that is Javascript comes to mind... or C/C++.
Heck even LSL has multiple interpreters that produce different
results based on the same "language" input.

Yeah, I know... semantics nitpicking, but I couldn't resist with...

For sure I understand this sentiment - but before you write off javascript entirely -- take a look at the work of/google tech talks by john resnik (inventor of JQuery). It may give you pause about JS -- and dynamically typed languages in general -- did for me

/esc