Re: porting portlib

[Mark Hindess <ma...@googlemail.com>]

In message <3b...@mail.gmail.com>,
Nathan Beyer writes:
>
> I've been playing around trying to port the portlib cod to run on
> Mac OS X 10.5. I've been futzing around with the assembly file in
> 'thread', specifically 'thrhelp.s' and 'thrspinlock.s'. I've been
> trying to find the lowest common denominator to work on Linux an OS X,
> but I've finally come to the conclusion that it's just not going to
> happen. Although most of the actual code - the implementations of the
> method are directly portable, the small stuff around it just doesn't
> work.
>
> The main issue revolves around leading underscores being added
> to function names. Apparently, this isn't the default behaviour
> for Linux, but it is on OS X - even though I'm using gcc and gas
> in both case. As such, the function names in the assembly files
> need to be different based on the OS. I've tried fiddling with the
> '-fno-leading-underscores' flag, but this blows up other stuff and
> just seems to be a rat hole.

Nathan, you are running down the wrong rat hole.

DRLVM doesn't use the threading code in classlib so fixing it is futile.
DRLVM provides its own libhythr.so - using the src in vm/thread/src.

I've never understood why we have a hy.thr.nodeploy option for the
classlib thread code.  If we aren't going to deploy it, why are we
building it?

(Aside: the originally contributed assembler code in classlib for
linux/x86 works but the later, Intel-contributed assembler code for
linux/x86_64 links but does not actually work in practice.)

> At this point, I think it's time to give up on the os.family + os.arch
> separation and change to os.name + os.arch or something else? Any
> thoughts or suggestions on such a change? I'm curious how this stuff
> works on the other unix platforms, such as AIX and BSD.

Well, the IBM VME for Aix uses the -Dhy.no.thr=true option so the
classlib threading code is not used.  But when I last tested it the
assembler code for x86 worked on FreeBSD.  However, this wouldn't stop
us splitting the code by os.name, we'd just use #include's to share
implementation where possible - much like we do with the hymmap.c code.

Regards,
 Mark.

Re: porting portlib

[Ian Rogers <ia...@manchester.ac.uk>]

2009/6/28 Mark Hindess <ma...@googlemail.com>:
>
> In message <3b...@mail.gmail.com>,
> Nathan Beyer writes:
>>
>> I've been playing around trying to port the portlib cod to run on
>> Mac OS X 10.5. I've been futzing around with the assembly file in
>> 'thread', specifically 'thrhelp.s' and 'thrspinlock.s'. I've been
>> trying to find the lowest common denominator to work on Linux an OS X,
>> but I've finally come to the conclusion that it's just not going to
>> happen. Although most of the actual code - the implementations of the
>> method are directly portable, the small stuff around it just doesn't
>> work.
>>
>> The main issue revolves around leading underscores being added
>> to function names. Apparently, this isn't the default behaviour
>> for Linux, but it is on OS X - even though I'm using gcc and gas
>> in both case. As such, the function names in the assembly files
>> need to be different based on the OS. I've tried fiddling with the
>> '-fno-leading-underscores' flag, but this blows up other stuff and
>> just seems to be a rat hole.
>
> Nathan, you are running down the wrong rat hole.
>
> DRLVM doesn't use the threading code in classlib so fixing it is futile.
> DRLVM provides its own libhythr.so - using the src in vm/thread/src.
>
> I've never understood why we have a hy.thr.nodeploy option for the
> classlib thread code.  If we aren't going to deploy it, why are we
> building it?
>
> (Aside: the originally contributed assembler code in classlib for
> linux/x86 works but the later, Intel-contributed assembler code for
> linux/x86_64 links but does not actually work in practice.)
>
>> At this point, I think it's time to give up on the os.family + os.arch
>> separation and change to os.name + os.arch or something else? Any
>> thoughts or suggestions on such a change? I'm curious how this stuff
>> works on the other unix platforms, such as AIX and BSD.
>
> Well, the IBM VME for Aix uses the -Dhy.no.thr=true option so the
> classlib threading code is not used.  But when I last tested it the
> assembler code for x86 worked on FreeBSD.  However, this wouldn't stop
> us splitting the code by os.name, we'd just use #include's to share
> implementation where possible - much like we do with the hymmap.c code.
>
> Regards,
>  Mark.

Just to note that MRP [1] uses the portlib threading code in Harmony,
it'd be nice if it worked on OS/X so thanks for your efforts Nathan.
As a consequence of using the portlib code although MRP runs on x86_64
with GNU Classpath it won't with Harmony (I've not test MRP with
Harmony x86_64 on Windows). It'd be nice if this was fixed. It'd also
be nice if there were a portable signal/stack/thread solution as a
package, I ran into various rat holes when doing this porting work for
MRP. I can provide the gory details if someone is interested in doing
the implementation work.

Regards,
Ian

[1] http://mrp.codehaus.org/

Re: porting portlib

[Sean Qiu <se...@gmail.com>]

Do we have an IBM VME for OS X? :-)

Best Regards
Sean, Xiao Xia Qiu




2009/6/29 Mark Hindess <ma...@googlemail.com>:
>
> In message <3b...@mail.gmail.com>,
> Nathan Beyer writes:
>>
>> I've been playing around trying to port the portlib cod to run on
>> Mac OS X 10.5. I've been futzing around with the assembly file in
>> 'thread', specifically 'thrhelp.s' and 'thrspinlock.s'. I've been
>> trying to find the lowest common denominator to work on Linux an OS X,
>> but I've finally come to the conclusion that it's just not going to
>> happen. Although most of the actual code - the implementations of the
>> method are directly portable, the small stuff around it just doesn't
>> work.
>>
>> The main issue revolves around leading underscores being added
>> to function names. Apparently, this isn't the default behaviour
>> for Linux, but it is on OS X - even though I'm using gcc and gas
>> in both case. As such, the function names in the assembly files
>> need to be different based on the OS. I've tried fiddling with the
>> '-fno-leading-underscores' flag, but this blows up other stuff and
>> just seems to be a rat hole.
>
> Nathan, you are running down the wrong rat hole.
>
> DRLVM doesn't use the threading code in classlib so fixing it is futile.
> DRLVM provides its own libhythr.so - using the src in vm/thread/src.
>
> I've never understood why we have a hy.thr.nodeploy option for the
> classlib thread code.  If we aren't going to deploy it, why are we
> building it?
>
> (Aside: the originally contributed assembler code in classlib for
> linux/x86 works but the later, Intel-contributed assembler code for
> linux/x86_64 links but does not actually work in practice.)
>
>> At this point, I think it's time to give up on the os.family + os.arch
>> separation and change to os.name + os.arch or something else? Any
>> thoughts or suggestions on such a change? I'm curious how this stuff
>> works on the other unix platforms, such as AIX and BSD.
>
> Well, the IBM VME for Aix uses the -Dhy.no.thr=true option so the
> classlib threading code is not used.  But when I last tested it the
> assembler code for x86 worked on FreeBSD.  However, this wouldn't stop
> us splitting the code by os.name, we'd just use #include's to share
> implementation where possible - much like we do with the hymmap.c code.
>
> Regards,
>  Mark.
>
>
>