World: r3wp

It's the JIT compiler that is used as the backend of DotGNU Portable.NET, 
among other projects. LGPL, generates x86, x64 and (experimentally 
so far) ARM. SSA intermediate code. We can make a compatible SSA 
REBOL dialect and build up a compiled dialect from there. The *existing* 
extension model is sufficient, no more changes required.

Tiny (about the same size as TCC), and a good first project that 
could be adapted to wrap LLVM if we like, as long as we keep our 
portion of the extension code license compatible with BSD.

this is REALLY interesting... that is exactly what my header scanner 
was being used for... indirectly.

it generated C code compiled by a (very high-eng) compositing software.

In case you were wondering, this is the main reason I was working 
so hard on R3 - so I could work on a project like this. Now that 
the parsing advancements are happening, soon R3 will be good enough 
for me to do my projects. For me, R3 will be released.

the reason this software (shake, now owned by apple) was so much 
faster at rendering, is that it wasn't a rendering software... it 
was just a C disguised C compiler :-)

when you pressed the render button, it actually compiled your project 
(in a matter of a few micro-seconds) and ran it.

Apple is moving rapidly to LLVM because they can't get the GCC project 
to cooperate. They already use it for iPhone development and OpenGL. 
Having a path to get to LLVM would be a good thing.

yes very.

and yes I'm interested.

I need this for ElixirOS.  its part of my roadmap for it  :-)

Cool. Btw, callbacks aren't required, nor are user-defined datatypes 
or function types. It turns out that commands are enough.

the reason I need callbacks is for event handling to be managed outside 
of REBOL.

I understand that you need them for your project - I just don't need 
them for mine :)

creating C binary code on the fly would allow us to go arround callbacks, 
but we still need them if we want external code to interact with 
rebol data on its own... no?

Not that I won't integrate devices and utypes when they are implemented.

Devices will handle synchronizing external processes with the REBOL 
interpreter, callbacks, asynchrony. That's the theory at least.

yep, that's what I imagined.

You go through devices so that you don't trip over R3's task model.

my callback example, really was similar to a device/port implementation 
IMHO.

its how it could be done and easy to use on both sides (C and REBO).

Your callback example may get raided for techniques that will eventually 
be used to implement the device model :)

that was the point  :-D

I like to think that I'm the godfather of extensions ... I did give 
them their name  ;-)

It was a good choice :)

btw, its cool that LLVM is used by apple... I plan to make ElixirOS 
run over apple's BSD kernel so that I have nice shiny boxes to run 
it on  :-).

Apple hired the lead developer of LLVM :)

that's cool.

how is LLVM any usefull to Apple?

PPC to x86 transition. x86 to x64 transition. OpenGL emulation on 
old video cards that don't support new features. Instruction set 
independence for the iPhone. Objective-C support in the front end 
that can be integrated with their development tools without license 
restrictions. A development commuunity that will accept their patches. 
The list goes on.

guys - shouldn't routine! and  and struct! datatypes be removed from 
R3? How are they usefull without R2 interfacing model? struct! was 
not optimal too (IIRC, some guys requested some enhancement to allow 
better nested structuring ...)

those could by later replaced by utypes, no?

For that matter, we probably don't need  the rebcode! placeholder 
type either.

As for LLVM for a target - what is the plan - to port entire REBOL 
into LLVM? Where can you find LLVM by default? Is it e.g. part of 
Linux distros?

Brian - so we should probably CureCode it, suggesting to remove those 
three?

Or let it in there, with following error message: "routine! is not 
available in REBOL 3. Please look into Extension concept ..." :-)

The standard REBOL DO dialect isn't compilable, though in theory 
PARSE could be if it were made less dynamic. What we could do is 
a compilable dialect that would resemble a subset of the DO dialect, 
similar to RPython of the PyPy project.

That is the theory at least. I haven't yet bought that REBOL isn't 
compilable - noone has proved it to me enough to stop trying :)

its compilable, but the code is self modifying, meaning, you need 
to track when that happens and jit compile it again.

subsets of rebol are more static, or could be with little loss in 
features.

Most of my code would be difficult to compile, but most conventional 
code should be fine :)

Actually, I'm convinced that more of REBOL is compilable, but that 
the process of compiling it is comparable to evaluating it.

my point has always been, that IN GENERAL, REBOL code is not compilable. 
that is, for every compiler you write, i can write a piece of REBOL 
code that is perfectly legit but your compiler can't compile. That, 
however, does not mean that you can't compile 99% of existing REBOL 
code. In fact, I do have a compiler that can handle most REBOL code 
(it's unfinished, i need to add some kind of type inference to make 
it useful enough). it can already take REBOL code as input, and produce 
optimized REBOL code as output.

also, JIT compilation is a whole differen thing than static compilation. 
You can probably JIT compile *all* REBOL code, however, it may be 
slower than the interpreter in some cases.

In either case, compiling REBOL requires thinking about REBOL and/or 
compilation differently, and trying to do so would push the envelope 
of compilation as a subject. And thus would make an interesting project 
:)

In general though, REBOL's semantics have been optimized for interpretation. 
As such, compilation may not give you as much of a speedup as you 
might otherwise think. This is why I was thinking of a dialect with 
semantics that would be more appropriate to compile. The syntax could 
be the same (to save on parsing code), but the semantics subtly different.

I tried to compile an extension for R3. Compiled as a C dll, it's 
ok, but I need to compile it as C++,as I will use com calls. So far 
it seems that R3 is not compatible with a C++ compilation of the 
extensions. Any experience on that ?

yep, the reason is that the labels within the dll change when they 
are applied through the C++ compiler.

there has been talk about the possibility to declare the functions 
differently within the extension libs themselves... but I haven't 
had time to play around with this yet.

BrianH can probably give you some pointers on what to try out if 
you're a proficient C++ coder.