World: r3wp

Wrapper: not necessarily if you use a define as shown above.

The problem with that is that you have to do it for every function. 
It's more work, in a different place than the #import. It feels like 
a hack, whereas return: [logic!] lets the compiler know the exact 
type

Well, that is the default behaviour already. You just have to be 
sure that the imported function is respecting that convention strictly.

Besides, the #define would still generate the extra code, wouldn't 
it? There's currently no way to specify that no conversion is necessary 
for a return value

Just don't use any type casting and no conversion code will be added.

But will integer! than be handled as logic! in expressions?

Certainly not, but we were talking about an imported function with 
a return: [logic!] declaration?

Well, that was my original question, whether that already works as 
I would like :-)

So it can only be used when strictly 0 and 1 are returned in integer! 
format?

Exactly.

OK, thanks

If you function return 0 for false and a positive number for true, 
it needs a runtime conversion.

Fair enough

Any plans to implement automatic inlining in the future?

Yes, but probably as part of a future optimizing compiler version.

So, probably when Red/System will be rewritten in Red.

I would also adopt a fastcall convention as default for Red/System 
function calls.

Awaiting that, I'll refrain from the #define solution, then

Andreas, Kaj: what were the changes required on ELF emitter to make 
it work on Syllable? Just entry point address?

Base address, really, and address alignment

Ah, yes, base address, not entry point. Thanks.

Base address for Syllable Desktop is 80000000h which currently needs 
to be coded as -2147483648

The same change would be necessary for BeOS, by the way

Red/System can now generate dynamically linked ELF binaries.

Along with some additional pre-processor directives added (#if, #either, 
#switch), this now enables the Red/System runtime being fully writen 
in Red/System itself.

If someone wants to test the generated ELF binaries on Syllable, 
I have a pre-built "hello.reds" available at http://bolka.at/2011/tmp/hello-syllable.bin

btw, I tried to install syllabe within VirtualBox some weeks ago, 
And It failed/

Andreas: tested on Syllable, works flawlessly!

Oh, great to hear :)

Wouldn't have expected that, actually.

Is it compiled with C bindings? (length? == strlen( ))?

Compiled with the current default settings.

So yes, with C bindings.

readelf says that alloc, free, memset, memmove, strlen are imported 
in the binary.

malloc*

Steeve: which system image file have you used?

Great! :)

I check it

SyllableDesktop-0.6.6.i586.iso

I am currently working on runtime error catching. I have successfully 
redirected default handlers for SIGILL, SIGSEGV, SIGFPE on Linux, 
but on Windows, the systems seems to ignore my handlers (using signal( 
) function). So I am currently testing with SetUnhandledExceptionFilter() 
(http://msdn.microsoft.com/en-us/library/ms680634%28VS.85%29.aspx)

If anyone has experience with that API on Windows, advices and tips 
are welcome. :-)

Steeve: I failed to install that version too, but here are special 
install images for Vmware and VirtualBox under "Emulate Syllable" 
bar here: http://web.syllable.org/pages/get-Syllable.html#installation-CD

Thanks, I'll try it

My Syllable image on Vmware works well (as long as I keep the mouse 
in the VM during the boot sequence, else it fails to be detected).

Btw, How do you use a Vmware image instead of an iso one. I don't 
see any option to do so with VirtualBox

You just do from menu: File->Open.

(on Vmware)

Hmm...

Great to see continued progress on Red!

Thanks Gregg, we are currently reaching the first milestone of the 
project with a fully capable Red/System language, just a few more 
implementation fixes, the specification draft to complete, and I 
will declare it beta (means "usable" for real work).