Introduction to Linden Scripting Language
prostoalex writes "Dr. Dobb's Journal runs a lengthy introduction to Linden Scripting Language, the language behind avatars and their interaction in Second Life: "LSL is a scripting language that runs server-side, on a piece of software called the simulator. The simulator does just what it's name implies — it simulates the virtual world of Second Life. Each simulator runs everything for 16 acres of virtual land — buildings, physics, and of course, scripts. While you manipulate the script text in a form that is somewhat easy to read, the actual code that runs on the simulator is compiled. A compiler is a piece of software that takes the text version of the script and converts it into something that can actually run. In the case of LSL, the compiler exists within the Second Life viewer itself. In the future, it is likely that the compiler will move from the viewer into the Second Life simulators, but where the code is compiled isn't very important. What matters is that the text is converted into a form that can run on the simulators.""
Is this a way for Linden Labs (and possibly for others) to provide closed source scripts and objects? This seems to be a very possible thing with such technology.
What if someone only made available a compiled copy of something? It'd be scary if you can't tell what's really going on with all the stuff.
Credit where credit's due, it's important to note that LSL is the first scripting language to have furry specific classes. This is an oft-overlooked aspect of modern languages.
There was talk about converting the server-side scripting engine to Mono, with huge (50x) performance gains. There was supposed to be a LSL->CIL compiler at first, then libraries for other .Net languages.
Has anyone heard anything about this recently?
"A compiler is a piece of software that takes the text version of the script and converts it into something that can actually run."
Glad that's all cleared up!
AT&ROFLMAO
The article isn't much better. It spends a lot of time going over what most Slashdotters already know, like what an "integer" is, and very little on what's novel about a scripting language for an interactive world (or whatever you want to call Second Life.)
hello class, this is a COM-PU-TER. computers run a set of instructions called a PROOOGRAAAM. programs are nothing but 1's and 0's. heheheh, but we don't program in 1's and 0's, we program in a language, such as linden script. another computer program, called a com-pi-ler, compiles the script into a format the computer can understand. ok, class, this is a DISK DRIVE . . .
sheesh, i thought this was
(actually, it must be -- even *I* am complaining about the summaries...)
mr c
"Physics is like sex. Sure, it may give some practical results, but that's not why we do it." - R. Feynman
I was expecting a tutorial on how to program an army of flying penises to interrupt a virtual press conference...
...or have done, really. The language is a bastard child of C, basically. Its major problem is its lack of arrays; you have a strange construct called a list that sort of does the same thing, but I really don't know why it's there instead of arrays. LSL is fairly underpowered. What I've taken to doing is using its HTTP system, though, to ping my web server, do something, and feed it back into the game. To do anything really impressive with LSL, it does seem to take an outside server to do the heavy lifting. It's kind of fun, though...
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
The summary quote uses 108 words to explain that there exists a compiler for this language.
The compiler sucks. For example, when you define a vector, it generates three "float literal" instructions rather than one "vector literal" instruction. This means that 2 instructions and 2 bytes more code than necessary are generated for each vector literal in the code (similarly with quaternons/rotations). (Remember, there's a 16Kb per script limit for code+data.) As a second example, there are two types of instruction for transferring data from the stack to local/global variables - store and pop (which is equivalent to a store, followed by a drop). For one, the compiler only ever seems to use the "pop" variant, whilst for the other it always uses a "store; pop" pair (despite this being inefficient) - I've never seen a lone "store".
Also, the goto is broken - due to a compiler bug/design error, only the last jump to a particualr label actually does anything. (The code for matching gotos to labels can only track one goto for each label.) This is a long-standing and well-known bug which I doubt would be difficult to fix, yet no-one's bothered.
There are also other useful instructions which are never used (such as various dups, an instruction for setting the instruction pointer directly - making jump tables/efficient switch statements possible - and an instruction for freeing arbitrary amounts of stack quickly). The compiler never optimises anything, either. It's why I don't hold out much hope for speed improvements from Mono (and indeed, the predicted improvements mostly vanished when they started running actual LSL scripts with it.)