WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

	Bottom Previous Topic Next Topic
Register To Post

(1) 2 »

salass00

Posted on: 2012/12/16 11:07 #1

Just can't stay away

I'm working on a port of ruby-1.9.3-p327 to AmigaOS 4 and as part of this I am working on the system dependent thread implementation code.

What has me confused currently is the implementation of the native_thread_init_stack() function which apparently allocates a region of the thread stack for some kind of virtual machine.

This is what the win32 version of the function looks like:


static void

native_thread_init_stack(rb_thread_t *th)

{

    MEMORY_BASIC_INFORMATION mi;

    char *base, *end;

    DWORD size, space;



    CHECK_ERR(VirtualQuery(&mi, &mi, sizeof(mi)));

    base = mi.AllocationBase;

    end = mi.BaseAddress;

    end += mi.RegionSize;

    size = end - base;

    space = size / 5;

    if (space > 1024*1024) space = 1024*1024;

    th->machine_stack_start = (VALUE *)end - 1;

    th->machine_stack_maxsize = size - space;

}

To me it looks like it's allocating from the upper end of the stack for this and leaves space on the lower end, but shouldn't this be the opposite as FWICT from googling Windows should have a decreasing stack same as AmigaOS?

Also looking at the pthreads version only makes things more confusing as it seems to use the entire stack region leaving no space at all for the thread to use for auto variables?

Edited by salass00 on 2012/12/17 21:47:34

salass00

Re: Ruby native_thread_init_stack() implementation

Posted on: 2012/12/16 12:21 #2

Just can't stay away

I think the 1MB region at the lower end that the win32 implementation leaves unused is the 1MB that Windows uses as a guard area so I will use this code for now which should be equivalent to the pthread version:


static void native_thread_init_stack(rb_thread_t *th)

{

    struct Task *me = IExec->FindTask(NULL);

    th->machine_stack_start = me->tc_SPUpper;

    th->machine_stack_maxsize = (char *)me->tc_SPUpper - (char *)me->tc_SPLower;

}

Edited by salass00 on 2012/12/16 12:36:41

corto

Re: Ruby native_thread_init_stack() implementation

Posted on: 2012/12/17 9:28 #3

Not too shy to talk

I have to say that the description of the MEMORY_BASIC_INFORMATION structure is not clear to me ...

With what you propose in the second comment, is there no risk for a thread to overwrite the stack top of the process ?

Anyway, that's very nice to see that you are working on this port. I am interested in Ruby (and ported the existing version on OS4, but quite limited).

salass00

Re: Ruby native_thread_init_stack() implementation

Posted on: 2012/12/17 12:54 #4

Just can't stay away

After a lot of work I now have a fully compiled and more or less working ruby command with extensions as shared object files.

I have tested it with some simple ruby scripts and it appears to be working correctly FWICT.

Ruby gems is disabled at configure for now and not working.

ssolie

Re: Ruby native_thread_init_stack() implementation

Posted on: 2012/12/17 19:56 #5

Amigans Defender

Quote:

What has me confused currently is the implementation of the native_thread_init_stack() function which apparently allocates a region of the thread stack for some kind of virtual machine.

I have no idea what they are up to but you might want to ping the developer list for help.

ExecSG Team Lead

ssolie

Re: Ruby native_thread_init_stack() implementation

Posted on: 2012/12/17 19:58 #6

Amigans Defender

Quote:

I have tested it with some simple ruby scripts and it appears to be working correctly FWICT.

When I was working with Python one of my goals was to get as much of the test suite working as possible. I imagine Ruby comes with an extensive test suite as well.

ExecSG Team Lead

salass00

Re: Ruby native_thread_init_stack() implementation

Posted on: 2012/12/17 22:13 #7

Just can't stay away

@ssolie

I think native_thread_init_stack() is probably supposed to report the full stack and then ruby itself decides how much of this is it wants to use. I can't see how it would work otherwise.

It has some pretty long and complicated code for detecting and handling growing and decreasing stack pointers. TBH I'm not sure why they didn't just allocate an area from the free store using malloc(). Would have been a lot easier and safer.

What I'm now working on is getting gems working. Ruby gems is a package management system for Ruby extensions, a bit like apt-get but for Ruby only and the packages are called gems.

First in order to be able to run the gem script (Ruby gems is itself written in ruby) I had to fix a couple of issues:
1. A path issue with dlopen() (apparently it doesn't like unix-style paths even when linking with -lunix)
2. An unresolved runtime reference in encdb.so (it was referencing a function in the main ruby exe so I had to add -Wl,--export-dynamic to LDFLAGS for the ruby exe)

spotUP

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/17 22:34 #8

Just can't stay away

You rock Salass00! \o/

spotUP

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/17 22:38 #9

Just can't stay away

It would be fun if you ported ruby/sdl too! :)
http://www.kmc.gr.jp/~ohai/rubysdl.en.html

ssolie

Re: Ruby native_thread_init_stack() implementation

Posted on: 2012/12/17 22:52 #10

Amigans Defender

Quote:

1. A path issue with dlopen() (apparently it doesn't like unix-style paths even when linking with -lunix)

dlopen() is just a wrapper for IElf->DLOpen() so perhaps it doesn't have the usual path conversion code in dlopen() yet?

Luckily, you can go look now for yourself.

Quote:

2. An unresolved runtime reference in encdb.so (it was referencing a function in the main ruby exe so I had to add -Wl,--export-dynamic to LDFLAGS for the ruby exe)

Yes, that will happen from time to time. The same problems occur with REBOL and Python.

With REBOL and Python we use real Amiga paths and don't try to fake things. It tends to be a lot more work to convert everything but the end result is nicer.

ExecSG Team Lead

salass00

Re: Ruby native_thread_init_stack() implementation

Posted on: 2012/12/18 16:41 #11

Just can't stay away

After a lot of debugging and some more minor fixes ruby gems can now connect to and download gems from the gem server.

spotUP

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/18 16:44 #12

Just can't stay away

\o/

kas1e

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/18 16:53 #13

Home away from home

Quote:

You rock Salass00! \o/

He is for sure. Now .. when he will write new workbench replacement for os4 ?:)

Join us to improve dopus5!
AmigaOS4 on youtube

samo79

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/18 22:11 #14

Home away from home

@all

To see how salass is awesome for this community just look to his software's list

http://www.a500.org/

afxgroup

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/19 8:37 #15

Amigans Defender

Ok Fredrik.. now come back to work on that other thing!!!

i'm really tired...

salass00

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/19 22:07 #16

Just can't stay away

@afxgroup

I did some work on the other thing this morning (assuming you mean what I think you mean

). Unfortunately it's still not doing anything useful. Much documentation reading and debugging ahead there.

Regarding ruby I just managed today to create and install a native gem (libxml-ruby to be precise). At the moment it required me to edit the extconf.rb script a little in order for it to work 100% correctly but hopefully I should be able to make it work without too much such changes in the future.

afxgroup

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/20 8:46 #17

Amigans Defender

yes.. i mean what you understand...

if you need help you only have to ask.. not to me but you know

i'm really tired...

salass00

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/21 9:57 #18

Just can't stay away

@spotUP

Quote:

It would be fun if you ported ruby/sdl too! :)
http://www.kmc.gr.jp/~ohai/rubysdl.en.html

Edited by salass00 on 2012/12/21 14:18:29
Edited by salass00 on 2012/12/21 15:10:38

Raziel

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2012/12/21 15:21 #19

Home away from home

@salass00

/we are not worthy mode

Resized Image

/we are not worthy mode off

@orgin

We need a "We are not worthy" smiley

--

game box/art scans
scummvm infrequent builds

salass00

Re: WIP port of Ruby-1.9.3-p327 for AmigaOS 4.x

Posted on: 2013/1/23 20:41 #20

Just can't stay away

The Ruby Documentation (RDoc) system will be enabled and working in the next release of Ruby for AmigaOS 4.x.

Obtaining documentation on Array.sort using ri:
Quote:

10.OS4.1:System/Ruby/bin> ruby ri Array.sort
= Array.sort

(from ruby core)
------------------------------------------------------------------------------
ary.sort -> new_ary
ary.sort {| a,b | block } -> new_ary

------------------------------------------------------------------------------

Returns a new array created by sorting self. Comparisons for the sort will be
done using the <=> operator or using an optional code block. The block
implements a comparison between a and b, returning -1, 0, or +1. See also
Enumerable#sort_by.

a = [ "d", "a", "e", "c", "b" ]
a.sort #=> ["a", "b", "c", "d", "e"]
a.sort {|x,y| y <=> x } #=> ["e", "d", "c", "b", "a"]

10.OS4.1:System/Ruby/bin>

I had to disable it during configure before because the ruby version on my cross-compilation system was too old (1.8.?) but I've updated it to 1.9.3 now so that I can leave it enabled.

Register To Post	(1) 2 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )