World: r3wp

Polymorphic.

(That's only when you use interpretation for the VM implementation. 
If your VM implementation is a JIT-compiler, register-based VMs match 
typical target architectures more closely, as Brian mentioned.)

I have only done very little in compiler optimisation, so it can 
only be better, I guess.

Andreas: The compelling evidence being Lua, which is the main register-based 
VM in popular use for which that is true. However, that depends on 
a number of other factors, not the least of which is the target architecture, 
or instruction-set design, or how well the register model maps to 
the underlying register model. It might be noted that there are not 
that many hardware platforms with 192-bit registers, so that might 
affect things.

Geomol: Are series operations included in your polymorphic opcodes, 
like they are in REBOL? Or are you sticking to the C-like opcodes?

Brian: the compelling evidence being http://dl.acm.org/citation.cfm?id=1328195.1328197

That you will need to figure out yourself within a few days. It's 
more fun that way. :)

Andreas: So in the case of register-based hardware architectures 
with a lot of 64bit registers (AMD64, PowerPC, Alpha), for a value 
space that rarely has direct values more than 64bit in size (the 
JVM model) implementing a variable-based procedural language rather 
than a stack-based language, a register-based model is faster than 
a stack-based model. Yup.

I'm surprised that in that case the register-based VM is only a small 
amount faster than the stack-based VM. Their register-based VM most 
have been crappy.

most -> must

Or their stack VM rather good. But we're getting seriously off-topic 
here.

(And I'm not surprised. The target architectures characteristics 
you mentioned above (reg count, width) are far less important than 
you seem to assume when implementing the VM using an interpreter.)

Back on topic: Do World's compiled functions implement the modifiable 
immediate block semantics of REBOL?

Well the claimed speed improvement is confusing me.
R3 slower than R2 on the Geomol's computer, uh !

And sorry but I also think that the memory footprint of the bytecodes 
is outrageous :-)

I faintly remember that R3 was slower than R2 for many things I benchmarked 
as well.

I guess it's better than R3's 128bit bytecodes :)

On a Mac again ?

On Linux.

128bit < 256bit, so no :)

Brian, the size of a Geomol bytecode is twice the size of a Rebol's 
cell

:)

It's outrageous! :)

I need to get things done, and get things rolling, so I won't answer 
any more questions at this point. You get the last countdown tomorrow, 
and the intro and being able to try it out yourself in 2 days, if 
all goes well.

Again thanks for the interest! And remember to have fun!

Sorry, I missed that. So it's a VLIW VM, like Itanium. Not quite 
the same thing as Lua at all. So we should believe him when he says 
"I have only done very little in compiler optimisation", but at least 
we don't have to worry too much about running out of opcode space.

This seems like it's made for big hardware. Interesting :)

No, it has nothing to do with VLIW except large insn size.

VLIW definitely was not invented to hold larger immediates :)

So it's big iron RISC then :)

Carl's partly open source model hasn't worked in attracting users 
and generating an incom stream for him .. why do you think yours 
will ?  ( for the FAQ )

I wonder how well the book sales idea would work. A side-effect benefit 
of that is good documentation for the language and some marketing.

Carl did that for the 2.3 core user manual but never had any updates 
to it.

I just paid for the ebook Programming with Clojure ... and that' 
s an open source lanaguage

:)

Like I said, when World is version 1 and I have written a good manual, 
it may make good sense to fully open source it.

The book I bought is not by the language author!

So if I open source it now, someone else could write the docs and 
benefit from it financially. Where would that leave me? :)

Like I was telling you earlier, Graham, you can't just open source 
something without considering the business model. Otherwise you're 
just giving away your work without it being sustainable.

In this case, the big iron aspects of this language could lead to 
some interesting potential applications. Big numbers work can be 
really useful.

Another nice change to REBOL for sure, where we unfortunately never 
got 64-bit builds.

To really use as much memory as we need. We hit the R2 memory limit 
already with one of our apps.

does binding work similarly to REBOL?  I mean can World support current 
advanced REBOL block binding/building for generating code like Parse 
compilers or such oddities like this:
>> reduce [ word word word ]
== [1 2 3]

I'll address that after release.

single level Mark and Sweep GC?  or did you put a bit of time into 
making it a bit more powerful (multi-zone, multi-level, multi-threaded, 
etc.) ?

World doesn't use garbage collection, but reference counting.

@Geomol .... it leaves you famous :)

Open source doesn't mean it's not copyrighted

I'm afraid of being famous. ;)

Write the book now :)

I'll do my best! I promise that.

The nice thing about the book I bought is that I can report errata 
directly from the pdf ... click on errata and it takes me to a web 
form

And the PDF has my name embedded in it ..