Terebi

[Zod]

As a few of the folks at on Dead Souls Demo know, I've been working on a new (from scratch) LP Driver.
(I know I'm not the only one)

It's a Java based driver, compiling LPC into Java Byte Code.

My driver hasn't gotten too far, but it has reach a major milestone - it is able to compile the Dead Souls ⁽¹⁾ sefun object into a (mostly) working java class.

The good

• It can parse (almost) all of Dead Souls 2.8.4
• It can compile the sefun object (and could probably compile a lot more if it knew how to handle calls to simul-efuns)
• LPC objects can (loosely) interact with objects written in Java

The bad

• It makes no attempts to be efficient yet - in either performance or memory usage.
• The function signatures for almost all the efuns are defined, but very few are implemented.
• Even though the sefun object loads, most of the functions don't work, due to missing support in the runtime
• Not all LPC constructs are supported by the compiler yet (e.g. do { } while(xxx); )
• Lots of stuff that I think works, probably doesn't 

The Ugly

• Under the covers the compiler is actually translating LPC to Java, and then running that through the eclipse compiler to generate byte code. That's a temporary measure - it's a lot easier to get the semantics right by taking this approach, but at some point I'll need to output byte code directly.
• There's no networking, game drivers, etc. etc. For now it's just a LPC -> Java compiler.
• The code works, but it's not especially elegant.

If anyone's interested in grabbing a copy, then head to
http://bitbucket.org/tvernum/terebi/ or http://www.terebi.us/
Currently there's no source bundles - you'll need a mercurial client to grab the code, and there's no build instructions (but given the limited usefulness of the code, it's probably no great loss)

Thanks to the folks at DS Demo who I've bounced ideas off - particularly Silenus - and to Anarres who happened to provide the starting point for the preprocessor (which I then hacked around a bit to support parsing LPC)

⁽¹⁾ That's Dead Souls 2.8.4, with a few patches to work around places where my compiler is more strict than FluffOS - I didn't have to do anything about the cases where I'm less strict

[cratylus]

Interesting.

What's the licensing on it?

-Crat

[Zod]

The code that has been written so far (the compiler) is Apache licensed.

I anticipate using a different license for the game server, and at the moment I'm leaning towards the Affero GPL (http://www.gnu.org/licenses/agpl.html)

That would apply only to the driver (there would be no tainting of the mudlib/game).
I think it gives the right balance

• It is free for people to use
• It allows derived works to be distributed
• It allows community mud (hobbyist muds) to charge for access, etc.
• It allows for fully commercial muds too, but forces them to publicly release any driver changes they make, which I think is a fair deal.

I am open to another license if someone has a good argument for it.
 

[sunyc]

The compiler is written by hand? or generated by antlr?

[Zod]

The parser is written with JJTree (JavaCC)
The compiler is written by hand by processing the AST from the parser.

[diskfulled]

BAD IDEA

[Zod]

BAD IDEA

Perhaps you could be more specific - what is it that you consider to be a bad idea?

[diskfulled]

lpc->LVM=>run SpeedA
LPC->Terebi ->JVM=>run SpeedB
SpeedB>SpeenA
SpeedB>>SpeenA

[sunyc]

what's the big difference of JVM and LPC -VM?

would it make it a lot slow? I don't have enough knowledge,but I doubt it.

Actually I see this an pretty good idea, although I strongly suggest use modern compiler framework such as antlr.

and will it be possible that we can do it by LPC->JAVA and compile with openjdk? An problem I can forsee is the type problem, but I am sure we can get around it?

[diskfulled]

sunyc frm china?

[Zod]

what's the big difference of JVM and LPC -VM?
would it make it a lot slow? I don't have enough knowledge,but I doubt it.

No reason why it should.
The JVM is the most advanced virtual machine currently in existence. It's designed to support Java, but it does a pretty good job of being a general purpose VM. There's absolutely no reason why it would be slower than the LPMud VM. The opposite should be true - with a well written LPC->Java Byte Code compiler (and terebi does not (yet?) qualify as "well written") you should find the JVM to be noticably faster than the LPC VM.

Not that it's particularly important - raw speed is rarely the key driver.

Actually I see this an pretty good idea, although I strongly suggest use modern compiler framework such as antlr.

I think you misunderstand - JavaCC does everything that Antlr would have done for this project.

and will it be possible that we can do it by LPC->JAVA and compile with openjdk? An problem I can forsee is the type problem, but I am sure we can get around it?

It's possible. But not as simple as you'd want. For now all lpc values are wrapped in an LpcValue interface.
That's quite normal with dynamic (+ semi-dynamic, like LPC) JVM languages.
I'm hoping to make it simpler and cleaner at some point, but it's not high on my priority list.

[quixadhal]

lpc->LVM=>run SpeedA
LPC->Terebi ->JVM=>run SpeedB
SpeedB>SpeenA
SpeedB>>SpeenA

As in the other thread about pre-compiled objects in FluffOS, diskfulled seems to have lots of opinions but refuses to put any hard numbers on the table to back them up.

sunyc frm china?

...

It's all well and good to believe that something is true, but some of us would like to see proof.  How do you know that that the execution speed of the LPVM isn't slower than the combined speed of Terabi's conversion to JVM + the JVM's execution speed?  Care to run a few tests and get back to us?

FWIW, I would assume that is IS indeed slower, however speed isn't everything.  Being able to use LPC in the licensing environment of Java would be a big plus to some.  A while ago, I tossed around the idea of adding LPC language support to the .NET envrionment, which would let you access an efun library for MudOS compatiblity, and also give you access to the .NET runtime AND let you mix in other languages at will (assuming you provided bindings for LPC data types).

[Zod]

I've pushed out a new set of changes to the public mercurial repository. (http://bitbucket.org/tvernum/terebi/)
A changelog is available at : http://bitbucket.org/tvernum/terebi/src/8c64a926c3b4/modules/lpc/CHANGES.text
The primary changes are

• class support
• Better function literal support
• Better binary operator support
• Additional working efuns

[silenus]

Hi Zod,

I can't remember but does Terebi compile to Java or to JVM bytecode?

[Zod]

I can't remember but does Terebi compile to Java or to JVM bytecode?

It currently compiles to Java.
The eclipse compiler works well enough in embedded form to the process pretty transparent (although a bit slow), and it's given me a massive head-start. It's much easier to analyse and debug Java code than byte code.

However, it does mean that I have a huge task ahead of me when I want to rip out the existing Java bank-end and put in a Byte code one.

I have a reasonable idea of how to go about doing that, but it doesn't make it easy.

Until that time, it will be important for the driver to cache a copy of the generated class files for the LPC source. (diskfulled will be pleased with that)