World: r3wp

The R3 module system uses an export keyword for marking its exports. 
Perhaps Red/System can use the same keyword.

Sure, that part is the easy one...Having quick look at "export" section 
format, it seems to be as messed up as the "import" one. Would probably 
need several days to make it work reliably.

For that matter, will Red/System be getting a module system, or some 
other kind of packaging facility?

We won't want to be limited to one-file programs forever :)

I'll extend it to allow compiling several sources in a single executable, 
but I won't go past that. Red/System will live as a Red dialect, 
so will benefit from the whole Red environment. The only time it 
needs to work alone will be to produce the Red's runtime layer. But, 
as said in my blog, Red/System could be extended to a full-featured 
language if someone want to invest in it.

In fact, support for incremental compilation is almost done, just 
needs testing/debugging. With that, you could feed the compiler with 
several sources while preserving its internal states and ask to "finalize" 
the job on the last one (means link the project).

Works here Doc. Congratulations!

Thanks Gregg.

Build hello.exe under OS X and works under Windows :)

Red/System is a cross-compiler. ;-)

Let me get this straight: Is this instead of using C?

Yup.

ok. that's all I need to know. :-)

great work doc!

Thanks.

Henrik: what an overwhelming enthusiasm! :-)

:-)

I went through the code and it's very impressive to me. Most people 
these days wouldn't think it would be possible

Doc, do you have Paypal account for donations?

he does .. see his cheyenne page for the address,

http://www.cheyenne-server.org/about.shtml

Thanks :)

Thank you very much for your donation Nick, that is very much appreciated!

the helloworld.reds script exe opens a console, writes stuff and 
then closes. Is there a way to keep that wndow open so I can see 
the output?

yes, run it from already opened cmd.exe

amacleod: It's mentioned in the README file:

4) The resulting binary is in red-system/builds/hello.exe, open a 
DOS console and run it.

Just wanted to say I really like the minimalist approach and am following 
this project with great interest.

I wonder Doc, why did you you choose to make your own compiler ?

And was OTCC behind your inspiration ?

There's some explanation in the comments on the Red website

I've looked at TCC sources for inspiration (don't know about OTCC). 
Making a compiler is at the heart of the project, Red (as Red/System) 
are compiled languages.

I've looked at TCC code emitter to be more specific, not at the compiler 
part.

OTCC is the ancestor of TCC

could LLVM also be a target for the emitter, eventually?

Right, looking at it right now, the one Bellard used to won the C 
obfuscated code contest.

Maxim: see http://groups.google.com/group/red-lang?hl=enfor the 
anwser to that question.

Short answer: sure, but it's not in the roadmap, I don't have a need 
for it.

But you know, I woud prefer a DSL like emiter, something using parse's 
rules exclusively

I needed to prototype a direct native emitter for the upcoming JIT-compiler. 
So compilation speed was a critical.

thanks, I was just wondering if the compiler was structured in a 
way to make it possible.


as for when/how that's obviously not a priority if you're already 
able to spit out code for the various platforms easily.

was a critical
 => was critical

Parse is fast

But I guess, you intend to recompile the emitter with Red itself, 
as soon as possible.

Yes, that's the idea. It's currently in a boostrapping phase, temporary 
relying on REBOL.

bootstrapping

I'm not sure I get your "DSL like emiter"? Do you mean compiling 
to an intermediate dialect, that would be compiled to native code?

No, I mean writing each target emitters/assemblers (IA32.r) with 
a dialect.

In a way to ease porting

But it's true that it's a matter of taste.

Such dialect would be an IR (Intermediate Representation), I wanted 
to avoid that, for several reasons: simplicity, efficiency, performances. 
The porting effort is not so big with the current approach. Also, 
once I'll start working on the optimizing compiler version (next 
year), I would  use need an IR, and it would need to be a little 
higher level than that (emitter/ASM-like level).