World: r3wp

yes

Actually, it's not rebol code, it just looks like rebol code :)

I see the len function hehe.   Do you have the dialect documented 
somewhere?

actually len here is an input... doh.

yes it is documented but the documentation needs to be converted 
to some format that everyone can read. Also the dialect  needs to 
be checked if it's without problems - it's three years old and probably 
needs more fixes to work with r3 without problems.

AFAIK, it supports most of the math, loops (loop, repeat, if...), 
conditions (if, either...).

Anyway, if you don't use the dialect (the command body is string! 
with c-code), the compilation should work without any problem.

Have you build it from the ground, or is it based on some of the 
opensource REBOLs (R#, ORCA)?

It's build from the ground. It parses the dialect and translates 
it to c equivalent (a: 5 becomes a = 5 and so on).

How is loops and conditions perform compared to REBOL, plain C, Lua, 
Python, ...? Maybe you have rough estimate on this?

well, now I read your comments again, I bet it perform very well, 
as it is simple translation to C, right? What about blocks, have 
you implemented them?

IIRC (the dialect is 3 years old and I haven't touched it for few 
years, I just made some fixes in last few days to run it under R3), 
most loops are translated to C's WHILE. You can try writing some 
RebC code and when you COMPILE it, in the %work/ directory you can 
find %your-filename.c file, where you can see the dialect translated 
to C. Do not expect it to be optimized in any way :)

Yes, exactly, it just translates to C.

Interesting anyway. :)

IIRC, there was some support for blocks as long as they can be converted 
to arrray. Now that the COMPILE part works ok, I can focus more on 
the RebC dialect to enhance it.

The main reason I wrote the dialect was to convert mathematic functions 
in Sintezar to C to make it faster and not write it in C as C syntax 
makes my eyes hurt :)

Good idea. And you have strong typing rules, right? So if a var is 
defined as an integer, you can't change it to something else along 
the way?

Hm, I'm not sure right now, I think it was possible to change it, 
but I may be wrong. But I think there were no error checks, it was 
just a basic version that can produce something working and I haven't 
much time to improve it since. That has changed recently.

Rebolek, about documentation, feel free to use NicomDoc: http://www.fys.ku.dk/~niclasen/nicomdoc/

It can easily produce HTML output as (MakeDoc), but also PDF output 
by first producing LaTeX.

Geomol thanks. Currently the documentation is written in special 
version of MakeDoc that supports literate programming so it's mixed 
with the source code.

rebolek, I will definitely check this out.  if you have any docs 
converted to html, I will read them, so know it will not have been 
done in vain ;-)

I was looking at making a libtcc extension, which would allow something 
like RebC to be used as a JIT compiler.

You wouldn't need to package your generated code as an extension, 
just generate to memory and run it from there.

Hm, that would be interesting.

The command! type makes this possible, since commands can dispatch 
to dynamically generated code if  need be.

Eventually I was going to make a libjit or LLVM backend, but it looks 
like I can get libtcc working sooner.

Not the first thing on my list though (which is HTTP) so if you want 
to take a crack at it first, I can help with the extension/module 
model.

It looks like libtcc can be statically linked into an extension, 
only providiing an extension interface to its functions.

Hm, I haven't looked at libtcc yet, but it it looks very interesting.

But first, I need to go thru the RebC code and improve it. It shows 
it's age :)

A command! is an indexed dispatch function, and the index has no 
inherent meaning. You could dynamically generate functions with libtcc, 
which would all have the same function signiature because they would 
just take command! call frames. These generated functions could be 
referenced from an array of function pointers. After you generate 
a new function and assign it to a new array slot, return the index 
of that slot to the calling REBOL code (embedded in the libtcc extension) 
and it can then make a command! with the libtcc extension's handle 
and that index. Then that command! can be called like any other REBOL 
function.


A trick though is that the generated C code would need to use the 
extension macros to manipulate the function arguments, rather than 
direct variable access. In other words, your generated functions 
would be extension-style code, not regular C code.

Pekr, the reason callbacks are so tricky in R3 is that you need a 
way to dispatch to the correct task within REBOL. R3 is not going 
to be single-tasking anymore, so direct callbacks will be impossible: 
You have to coordinate between the task/thread of the external code 
and the tasks/threads of R3. Devices manage that coordination and 
synchronization.

Bolek, if you have the commands that are exported from the libtcc 
extension themselves implemented as functions with the same signiature 
as the generated functions, you can call them through the dispatch 
array as well. This would reduce your RX_Call function to just a 
few lines.

Be sure to BSD the extension wraapper code though, so it can be reused 
by an LLVM wrapper :)

If you mean BSD-license, that's understood. I prefer PD/MIT/BSD licenses, 
GPL is stupid.

(I prefer no licenses at all, but I'm an anarchist)

Well, libtcc is LGPL (2, I think), as is libjit, but LLVM is BSD. 
The extension interface is LGPL compatible, so if you BSD the wrapper 
code (or more permissive, as long as it's LGPL compatible) then you 
should be fine.

I prefer more permissive licenses too :)

especially PD

I'm fine with PD - code is just organized characters. Milion monkeys 
with typewriters can do same thing ;) so why licensing anything. 
But that's offtopic - the license will not be deffinitely more restrictive 
than BSD and it may be PD as well. Depends on my mood when I add 
it to header ;)

libtcc is LGPL 2.1

Playing with the extension example: IMO it's done  to complicated.


- Why do I need make-ext.r? Do I always need it or just for this 
specific example?

- Why is the init block a const char array and not just a plain ASCII 
text?

How do I return a new string back to Rebol?

I seems I need to construct a RX string and set every single char?

This uniton gives a warning/error with mingw:

typedef union rxi_arg_val {

	i64 int64;

	double dec64;

	REBYTE bytes[8];

	struct {

		i32 int32a;

		i32 int32b;

	};
	struct {

		u32 index;

		void *series;

	};
	void *handle;

} RXIARG;

The structs give: warning: declaration does not declare anything

yes, Robert, the other elements clearly declare something, but the 
structs don't declare anything, the compiler is right

generally, struct {...} my-struct; declares my-struct, while struct 
{...}; does not declare anything

(should have been my_struct)

I commented the struct part and than it works. So either we need 
to give it a name, which will result in a ->struct_name.series sequence. 
Not sure if this makes any difference instead of just putting the 
members into the union.