World: r3wp

ok, thanks

The parsing functions in the C library binding can get you halfway

Got the cURL binding to work on Syllable, starting from Andreas' 
example. :-) Will research some more and report on the tracker

Good news!

just found this... it could be a good reference for low-level bit 
handling in Red.
  

though the code is in C, its probably easier to understand this way 
and convert to Assembly after (when no comparable machine instruction 
exists).
http://graphics.stanford.edu/~seander/bithacks.html

it has soooo many variations and its been thouroughly tested and 
analysed by thousands of people.

good sauce

Bookmark: "Calling conventions for different C++ compilers and operating 
systems" 

http://www.scribd.com/doc/51814542/36/Relocation-of-executable-code

Right link should be rather: http://www.scribd.com/doc/51814542/calling-convention

And straight from the source (I think we already had this here in 
the past):
http://www.agner.org/optimize/calling_conventions.pdf

You're right, and it looks like I missed it last time. Thanks for 
giving the right source link.

Got a very simple Red/System program running on OS X: 
    Red/System [ ] quit 42
;-)

It took me a few hours to write the file emitter but a full day of 
debugging to make it work. It seems that the issue was related to 
stricter stack alignment requirement on OS X (16 bytes alignment) 
and a different ABI for syscalls. 


It currently works thanks to a few hacks, but I need to extend the 
IA-32 emitter to implement these new requirements in order to make 
it output correct code for OS X.

Rebolek: I think that your first implementation should work once 
I upgrade the compiler.

For those curious about Mac OS X low-level ABI for function calls: 
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html

Doc, great news for those of us who primarily develop on OS X these 
days.

Not only those. I appreciate the ability to target OS X without having 
to run it or know anything about it :-)

16 Bytes stack alignment is also preferred/required for MMX/SSE

It seems GCC always uses it

http://www.cs.uaf.edu/2010/fall/cs301/lecture/10_27_sse.html

It also seems it's only required for system calls on OS X

http://stackoverflow.com/questions/612443/why-does-the-mac-abi-require-16-byte-stack-alignment-for-x86-32

happy to know that Mac version is in progress.

Actually, the link I gave to Apple's docs does not cover syscalls...I 
couldn't find any official Apple doc about that. MacOS X seems to 
conform to BSD syscalls calling convention.

I use #pragma pack(4) to control alignment. Read about it here:


http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/MakingCode64-BitClean/MakingCode64-BitClean.html

GCC 4.5+ uses/requires 16 byte stack alignment per default.

Hello.reds running on MacOS X: http://static.red-lang.org/MacOSX-hello.png

cool :)

Doc, another stupid question: Are there going to be certain platform 
specific parts of code in a Red/System program?

Only OS bindings.

But those defined in current Red/System runtime have an abstraction 
layer, so the runtime API is the same for users on all platforms.

I try to make sure that Red/System code can work the same on all 
platfoms (at least for 32/64-bit ones).

First MacOS X support version released: https://github.com/dockimbel/Red/commit/8b34c8684e273dd31b6778fc654f5e5548db6f37

There are still several things to fix in the runtime.

And I need to change the OS default selection code in the compiler, 
so that the `-t Darwin` option won't be required when running on 
OS X. That fix will also enable the unit tests to work properly.

Just reading %rsc.r, it seems Andreas already added such feature...there's 
probably a bug in compiler.r preventing it from working properly...

Ok, issue fixed, the `-t` option is no more required on MacOS X for 
native compilation.

Wonderful !!!

The unit tests run in approximately two-thirds of the time under 
OS X than they do under Windows/XP running under VirtualBox.

VirtualBox can make systems very slow

Kaj: what is the status of the issue #129 that you have opened? Does 
it still crash?

It's all in there. It doesn't crash with the added solution - which 
should become native

New editor in REBOL for Red/System : edit | compile | run for Windows, 
Linux, MacOSX !
http://www.red-chronicle.com/2011/07/new-red-editor-in-rebol.html

Make a docs directory in the rebol installation folder and type in 
REBOL console :
do http://perso.numericable.fr/frajouen/Red/editor.r

Very nice :-)

Very nice indeed. In GET-KEY, should 'cc be local?

About calling functions in shared libraries and calling conventions, 
there seem to be differences between CPUs and compilers across operating 
systems. There's a lib, called libffi, to help with this, and it 
has bee widely ported.
http://en.wikipedia.org/wiki/Libffi


Why isn't a lib like libffi used in Red? Is it because of overhead, 
making it slower? Or maybe using such a lib makes little sense the 
way Red is implemented?


When looking at the host-kit for R3, I see functions to open, close 
and find functions in DLLs, but I don't see the calling of those 
functions. Shouldn't that be part of the host kit?

I don't see the calling of those functions
 - the C compiler handles that.

As I understand it, it's about fetching and calling functions at 
runtime, not compile time, so is that really the case?

Red/System relies on shared libraries dynamic linking at load time. 
CPU and ABI specific calling conventions are handled by respectively 
Red's target emitters and file emitters. I don't see how libffi could 
make it simpler or better. From what I understand from FFI (very 
short) descriptions, it is more suitable for high-level languages 
that can't or don't want to deal with low-level interfaces.