r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

Kaj
5-Jul-2011
[2708x2]
The issue with shared libraries seems to be limited to the fact that 
cURL can use libdl. I don't know what was different now, but I got 
a GDb trace. Will put it on the tracker
The crashes seem to happen when cURL calls the C library, so outside 
the Red program. I'm not sure it's useful to disassemble a minimal 
Red example
Jerry
5-Jul-2011
[2710]
I have 37,000 followers in Sina Weibo (aka Chinese Twitter), Most 
of my follower's are programmers. I've just mentioned Red in Sina 
Weibo. I hope that will make Red be noticed in China. I would like 
to thank Dockimbel for Red.
Dockimbel
6-Jul-2011
[2711]
Jerry: thank you! 37k followers, that's huge!
Henrik
6-Jul-2011
[2712]
silly question: is it possible now to build a CSV parser in Red?
Dockimbel
6-Jul-2011
[2713]
There is no Red yet, only Red/System which is a low-level dialect. 
So, yes it is possible, but there's no special feature that would 
help you much for that task.
Henrik
6-Jul-2011
[2714]
ok, I was just looking into the idea if it was possible to build 
one with better performance than what I currently can.
Dockimbel
6-Jul-2011
[2715]
It will probably be much faster than the one you could write in REBOL, 
but you'll have to do all the memory management manually.
Henrik
6-Jul-2011
[2716]
ok, thanks
Kaj
6-Jul-2011
[2717]
The parsing functions in the C library binding can get you halfway
Kaj
7-Jul-2011
[2718]
Got the cURL binding to work on Syllable, starting from Andreas' 
example. :-) Will research some more and report on the tracker
Dockimbel
7-Jul-2011
[2719]
Good news!
Maxim
8-Jul-2011
[2720x2]
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.
Steeve
8-Jul-2011
[2722]
good sauce
Dockimbel
8-Jul-2011
[2723x2]
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
Andreas
8-Jul-2011
[2725]
And straight from the source (I think we already had this here in 
the past):
http://www.agner.org/optimize/calling_conventions.pdf
Dockimbel
8-Jul-2011
[2726]
You're right, and it looks like I missed it last time. Thanks for 
giving the right source link.
Dockimbel
9-Jul-2011
[2727x4]
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
Ashley
9-Jul-2011
[2731]
Doc, great news for those of us who primarily develop on OS X these 
days.
Kaj
9-Jul-2011
[2732x6]
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
Jerry
10-Jul-2011
[2738]
happy to know that Mac version is in progress.
Dockimbel
10-Jul-2011
[2739]
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.
Geomol
10-Jul-2011
[2740]
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
Andreas
10-Jul-2011
[2741]
GCC 4.5+ uses/requires 16 byte stack alignment per default.
Dockimbel
10-Jul-2011
[2742]
Hello.reds running on MacOS X: http://static.red-lang.org/MacOSX-hello.png
Andreas
10-Jul-2011
[2743]
cool :)
Henrik
10-Jul-2011
[2744]
Doc, another stupid question: Are there going to be certain platform 
specific parts of code in a Red/System program?
Dockimbel
10-Jul-2011
[2745x8]
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.
PeterWood
11-Jul-2011
[2753x2]
Wonderful !!!
The unit tests run in approximately two-thirds of the time under 
OS X than they do under Windows/XP running under VirtualBox.
Kaj
11-Jul-2011
[2755]
VirtualBox can make systems very slow
Dockimbel
13-Jul-2011
[2756]
Kaj: what is the status of the issue #129 that you have opened? Does 
it still crash?
Kaj
13-Jul-2011
[2757]
It's all in there. It doesn't crash with the added solution - which 
should become native