World: r3wp

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.

(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.