World: r3wp

Q: We already know that your physics background influenced the new 
complex numbers datatype. Should we expect further progress of this 
kind (physics/science)?

A: After pointing this language out to a couple of friends from university, 
I was quickly asked to give scientific examples, like making a Lorentz 
attractor. There will come examples like that. Also I have some contacts 
at the Niels Bohr Institute (Copenhagen University), that I would 
like to show the language to and see, if we can create some projects.


Q: How long has this been in the making in general & how much time 
have you spent programming it?

A: I started R&D late March 2009. In March 2010, I had >7'000 lines 
of C. Then I took almost a year break from World and started up again 
Spring 2011. I have used much time on it this year (2011). So I've 
used 1-2 years effectively, I guess.


Q: Is there a way loading and interfacing pure object files, how 
about callbacks?

A: I don't have much experience in this area. Two of the closed alpha 
testers have looked at interfacing with sqlite3, which uses callbacks 
for some stuff. I would say, it doesn't work 100% yet, but it's being 
worked on. I need to see examples of loading and interfacing with 
pure object files to judge, how much of such functionality should 
be in World.


Q: Wouldn't it be useful to treat the kwatz! type same way as binary! 
so you don't need to always convert it? I mean, all functions that 
are able to take binary! arg should be able to use the kwatz! as 
well...or do you think are there any problems regarding that?

A: I've thought of that and came to the decision, that KWATZ! should 
be treated with some care. Are we always sure, we want to treat that 
data as binary? I need more experience using KWATZ! to judge that. 
Conversion could be fast, if the AS function was introduced, which 
should just change the type without copying.


Q: Is there a call-in interface available, meaning I can embed World 
in other programs?

A: Not yet. Internally I do call World functions from C (to parse 
URLs) by pushing arguments on the VM stack and call the execute_vm() 
C function. I imagine an interface much like in Lua (lua_call), but 
a little more work is needed, before we're there. This is an alpha 
release, so things will change/be added, before we move to beta release.


Q: Regarding your thesis I guess you have something like an integrated 
db or a special datatype for permanent storage too.. ?
A: Too early! :)

Q: What subset of REBOL2 will run without change in World?

A: Uh, ah, hard to tell at this point. When I need new functionality 
in World (because I want to run some of my R2 scripts), I consider, 
if it should be part of World/Cortex or if the new functions should 
go into the REBOL expansion/dialect (%rebol.w). I want World/Cortex 
to be small and compact. The idea with %rebol.w is, that much of 
R2 code could run, after this script has run.


Q: Are there datatype and function comparisons between World and 
REBOL2?

A: No, I haven't documented that ... yet. Maybe someone else wanna 
document that!? But there are differences, like the REBOL decimal!, 
which in World is called real!. And then %rebol.w just include the 
line:
decimal!: :real!
, so REBOL scripts using that will run.


Q: How many people were working on this World? :) Is it just a single 
man project?
A: Yes, just me.

Q: Will there be a GUI?

A: I would really need a GUI for my own work at some point. I have 
ideas, but nothing set in stone yet. And I want World to be open, 
so different GUIs should be possible, also the native GUIs in the 
different OS.


Q: Are you rich enough to buy Rebol Technologies and employ Carl? 
:-)
A: [KWATZ!]

When we tried something similar to the LOAD/on-kwatz trick in R3 
(named LOAD/on-error there) it turned out to slow down LOAD so much 
that it made it unusable - something about switching back and forth 
between native and interpreter execution schemes. The alternative 
of having a kwatz! type returned had the effect of changing a load-time 
check for syntax errors in the source code into a runtime check for 
invalid values, but only if you are expecting such things and testing 
for them explicitly. Under normal circumstances a kwatz-accepting 
loader would often result in code that would run slightly wrong but 
not trigger an error to help you figure out why. This is why you 
should make sure that your regular code loader triggers errors by 
default when it encounters unexpected syntax. An option to be more 
forgiving would be helpful when loading dialects that explicitly 
support particular kinds of extended syntax - and thus are expecting 
kwatz! - or for loading user data for analysis.

Glad to hear that C-like code is faster in World than in REBOL :)

Overall the language seems rather Lua-like, with the same advantages 
and disadvantages of that model.

Yeah. I'm also glad, it's faster. That was some of the first tests, 
I did, long before you could call it a language.

One of the main reasons for making R3 was Unicode support. How it 
looks in the World?

I've dealt with unicode in some REBOL projects, simple by making 
functions to deal with it. I would initial do it like that in World, 
but on sight, a unicode! datatype would probably be a benefit.

The lexer is 7 bit, so words can only hold 7-bit ascii characters. 
String and other data is 8-bit.

REBOL can be blazingly fast if you use it for REBOL-like tasks. It 
has a different set of tradeoffs. Unfortunately for its image, most 
language-vs-language comparisons tend to have C-like code since it's 
the common denominator, and that makes languages that aren't optimized 
for that style of code look bad. However, if you have to do C-like 
tasks, a language that isn't optimized for them won't help you very 
much. This is one of the reasons that I like the REBOL spinoff languages. 
For me R3's model leads to the fastest code, but I don't have to 
do much C-like stuff.

I like to keep things simple, and I feel, implementing unicode everywhere 
very fast make things very complex.

Words are probably ok as ascii, but unicode! datatype is a must if 
you don't want to end with binary data instead which is doable like 
in R2, but ugly.

Wow.. another language!


I saw it mentioned few times that it's like Lua.. can someone explain 
it to me since I love some aspects of Lua very much and I don't know 
what you mean? (except I saw somewhere values are pushed to stack 
/ between c - world (which is probably similar to Lua)

I fear, that implementing unicode! datatype will mean, all series 
functions will have to deal with it separately, like LENGTH?, NEXT, 
SKIP, etc. Would it be an idea to make a unicode! datatype just to 
pass data back and forth and be able to view it somehow, but without 
support for all the series function?

@Janko, it's about the fact, that Lua implement a virtual machine, 
that runs the vm asm code, after Lua source has been compiled to 
that. World does it the same way, but in many ways, World is also 
very different from Lua.

Isn't 32bytes per instruction too much?

REBOL on the other side, interpret the REBOL source all the time, 
like every time the same function is called. In World, the function 
is compiled to VM code, the first time, it's called, after that the 
compiled code is just run (unless the source is compiled again).

Oldes, complex numbers hold 2 double = 128 bit, then OP-code, register 
pointer and maybe some more.

Janko: Compiled to a byte-code VM, it looks like a similar embedding 
model. The advantages of bytecode VMs are that they can be tuned 
to be faster for low-level operations that can match the VM author's 
needs, though most are optimized for C-like code, simple math and 
loop evaluation. The embedding model makes it so that you can embed 
in a C-language program (lowest-common-denominator) without affecting 
the language itself much, though the actual interface is slow enough 
that efficient code tries to avoid going back and forth across that 
barrier. Disadvantages are that higher-level operations tend to be 
slower than the lower-level operations that have bytecodes associated 
with them.

thanks for explanations to both of you. so it's more of a backend 
similarity

I wasn't aware of byte-code VM specifics .. so thanks for that too

Thanks for the comprehensive Q&A, John.

@Janko, look at "Countdown: 1" tomorrow.

You're welcome, Andreas.

I also think that 256-bit VM insn size sounds a bit wasteful. That'll 
thrash the data cache easily.

I'm not sure that holding complex values as immediates is worth it, 
even for complex-heavy code.

REBOL code is interpreted, but not its source. The slow part of a 
source interpreter is parsing the source into the intermediate code, 
the AST. REBOL is an AST evaluator. The advantage to that relative 
to a bytecode VM is that you can extend the runtime with more fast 
operations without breaking the bytecode encoding, but the disadvantage 
is that the interpreter overhead is larger so if you want your operations 
to be efficient you have to use larger ones. This is why C-like code 
is slow in REBOL, but high-level code can be fast.


If you want to get the advantages of a bytecode VM with the extensibility 
advantages of REBOL's model you could go with an address-threaded 
interpreter. Address-threaded interpreters have more data going through 
the processor than bytecode interpreters do, but it you need to support 
higher-level operations they are more efficient overall. However, 
if you don't need to support higher-level operations and only need 
to support a tiny number of low-level operations then bytecode can 
be encoded in a much smaller amount of space. If your language is, 
for instance, a spreadsheet formula evaluator then you might even 
be able to have 4-bit bytecodes, with two operations per byte, and 
have an interpreter that fits entirely in the instruction cache of 
a processor. Bytecodes can be much faster then.


Still, Lua's bytecode VM, as efficient as it is, has been running 
into performance limits as well. Fortunately, a bytecode model that 
maps well enough to the native code model (remember what I said earlier 
about C-like bytecode VMs?) can have the bytecodes translated to 
native code at runtime and then execute the native code. For C-like 
code that is usually even faster than address-threading. This is 
why LuaJIT has been doing so well when compared to Lua's bytecode 
VM.


World being Lua-like means that it can improve using methods similar 
to the ones that Lua has been using to improve. That's definitely 
a good thing, since it means that Geomol doesn't have to work from 
scratch :)

As you talk about registers in context of your VM, I assume that 
your VM is register-based, right? (Not stack-based.)

If you want to compare to a source interpreter, try old versions 
of TCL before it switched to bytecode interpretation. That was *slow*, 
not like REBOL at all.

If so, I'd probably try splitting immediate complex-loads into two 
insns. Then reduce insn size to 128-bit (if possible) and check the 
effect on code size.

Just a thought, though. You (John) probably already tried that :)

Looking very much forward to playing with World.

Uh, I'm not 100% on the technical terms. Registers are on a stack, 
and a register pointer is an offset. So you can have lots of registers, 
and the VM can access each of them very fast. Values can also float 
in memory (not on stack), and then we have a real pointer to it. 
See blog tomorrow.

Ah, then it's stack-based with deep access into the stack.

ok

Can you access registers that aren't on the top of the stack? Direct 
addressing, rather than stack operations?

Is that good? :)

Brian, yes.

That's not why I was asking :)

That will make the JIT easier then :)

But it's an even stronger incentive to keep instruction size small 
:)

As I assume that your stack slots/registers are also 256-bit wide?

The JITs for the JVM model have been notoriously difficult because 
they were strictly stack-based, which only made sense on the stack-based 
hardware the JVM was based on, not the register-based hardware it 
was being JIT-compiled to. One of the reasons LuaJIT is so good is 
that Lua's model is register-based.

Stack slots are 192 bits = 24 bytes.

Ok.

(As long as it's a 64b-multiple, thats fine.)

yup

Is your bytecode polymorphic, or is it statically typed? A polymorphic 
VM like REBOL's wouldn't have problems with higher-level series like 
unicode!, but to support that on a static-type VM you would need 
either a lot of opcodes or compiling to a lot of code to support 
it.

REBOL's actions are a polymorphic VM, btw.

(And to not evade that question completely: there is some compelling 
evidence that register-based VMs enable faster-performing VM implementations.)

Polymorphic.