World: r4wp

I don't believe Comment is a function in Red/System as it is in REBOL. 
I think it is more like a compiler directive.

A block will work with the compiler but not the pre-processor because 
the complier is working with loaded REBOL values whereas the pre-processor 
is probably working with string data.

Kaj: could you replace `print` by `putchar` in the Mandelbrot bench, 
so it is equivalent to the C version? (Not sure it would change much 
the timings, but at least, the sources will be equivalent).

`print newline` would then become `putchar lf`

In earlier tests it made no difference, but it may now because the 
times are small. Better test that without printing at all

A better way would be to increase the number of iterations

The preprocessor is block oriented now, isn't it?

Yes it is.

To be more precise, there's a string stage and a block stage in the 
preprocessor. All the compiler directive are processed at the block 
stage. The string stage is just a front-end to handle R2-incompatible 
syntax, like the Red/System hex notation, and count source lines.

Kaj: do you know why __libc_csu_init and __libc_csu_fini are not 
defined in libc in Linux? How am I supposed to pass them to __libc_start_main 
if I can't access them?

Don't pass them.

Isn't the libc doing important initialization and clean-up in these 
two functions?

Nope, they can safely be NULL.

__libc_start_main by itself is not doing much work, just a few calls 
and some global var init (like __environ). When I disassemble a C 
binary, these two calls are doing a lot of work.

well, __libc_csu_init and __libc_csu_fini are functions that are 
linked by gcc into the generated executable.

__libc_csu_init calls _init which in turn calls two more functions: 
call_gmon_start and __do_global_ctors_aux

call_gmon_start is support for the gnu profiler

__do_global_ctors_aux is for traversing ELF "constructors" (stored 
in a .CTORS section) which are then rnu

run*

as red/s neither supports elf ctors/dtors nor gprof, none if this 
should be needed

(again, all of the above are functions linked into the program binary 
by gcc)

okay, thanks for checking that.

i'm pretty sure none of that is needed for actual glibc setup

New commit pushed to `libc-init` branch, new simplified and more 
conforming way to init libc (at least I hope).

I need to add support for Syllable, I have the right doc from Kaj 
for that, so no problem.


For Darwin, I would need the right stack layout description on starting 
a new process, I haven't found yet a recent and official description 
for that, just a lost page in google's cache from 2009: http://webcache.googleusercontent.com/search?q=cache:4zQ0NwtOKdsJ:blogs.embarcadero.com/eboling/2009/10/13/5620+MacOSX+stack+layout+on+start&cd=4&hl=fr&ct=clnk&gl=fr

from that doc, the osx stack layout looks identical to linux/elf

(so that should be easy to try)

identical from the main() POV, but I'm not sure that's the right 
kernel stack layout before libc is initialized.

in that doc, it's not describing the stack for main() but the stack 
layout as setup for the entry point ("_start")

Yes, that's what I am after.

_start
 emulation

yep

so osx looks just like linux :)

Okay, libc-init is now working fine for Linux and conforming to Gcc 
ABI. Once again, man has won over the machine, but I wonder how many 
neurons were killed both in my and Andreas brain during the battle...;-)

the reverse ... you probably grew a few :)

It's a loosing battle

The documentation seems to describe that when you write a floating 
point constant, it will be a float32! if it fits. However, it turns 
out that it is interpreted as float64!

Indeed, the spec is misleading here. All literals are float64!, float32! 
has no literal form.

So the only way to construct a float32! from a literal, is by casting 
(`as float32!`) from a float64! literal.

(So it's propapbly best to remove the "syntax" section in the float32! 
spec and add a note describing the above.)

Agreed.

Doc fixed.

I found another freak bug

ah?

In the tracker

Kaj: proper libc init code added for Syllable. It works fine on my 
Syllable VM.

That is great, thanks!

Doc - so your sister tweets about the Red development? Cool :-)

Why not delete the Twitter message if it was an error?

Good movie?

Behold, an OpenGL triangle rendered by a Red/System program:
http://earl.strain.at/share/reds-opengl-triangle-20120227.png