You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Marina Goldburt <ma...@gmail.com> on 2006/07/25 11:13:27 UTC
[classlib] porting to other platforms
Hi,
I'm interested in the task of porting classlib to the 64bit platform
(em64t/amd64).
At this moment, classlib's source structure and build system doesn't support
the diversity of platforms.
Let's discuss what changes have to be made to support other platforms.
One way is to move platform-dependent to the appropriate directory. For
example,
port--linux --ia32
--em64t
--ipf
makefile
and to add platform determination and proper files selection to the
makefile.
The other way is to select the platform-dependent code by the preprocessor
difine directives and to include the platform determination and the difines
setting to the top-level build files (unfortunatly it doesn't work with asm
files).
Any thoughts?
Thanks, Marina.
Re: [classlib] porting to other platforms
Posted by Enrico Migliore <en...@fatti.com>.
Hi
> Hi,
>
> I'm interested in the task of porting classlib to the 64bit platform
> (em64t/amd64).
> At this moment, classlib's source structure and build system doesn't
> support
> the diversity of platforms.
> Let's discuss what changes have to be made to support other platforms.
> One way is to move platform-dependent to the appropriate directory. For
> example,
> port--linux --ia32
> --em64t
> --ipf
> makefile
> and to add platform determination and proper files selection to the
> makefile.
I always do this way when it comes to write multi platform code because
I like to keep everything clean and organized.
> The other way is to select the platform-dependent code by the
> preprocessor
> difine directives and to include the platform determination and the
> difines
> setting to the top-level build files (unfortunatly it doesn't work
> with asm
> files).
>
That taints the code but it's the most used way, and of course, assembly
code should reside in separate files.
Multi-platform code forces you to deal with the triplet:
CPU, OS, Compiler
Enrico
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] porting to other platforms
Posted by Marina Goldburt <ma...@gmail.com>.
Dmitry,
As noticed in the letter
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/%3c449B0751.8000209@gmail.com%3e
hythreads module is not used by the DRLVM (the VM used in Harmony official
JRE and HDK snapshots) and by j9 vm too. I don't know about JCHEVM and
BootJVM (if somebody knows, please, tell are they use the hythreads library
or not?).
So, I think, the first step might be to port the parts of classlib required
to get working em64t/ipf JRE snapshot.
Marina.
On 7/25/06, Dmitry Yershov <dm...@gmail.com> wrote:
>
> At first, all assembler files should be propagated to the 64bit platforms.
> e.g.:
>
> <classlib>/modules/luni/src/main/native/thread/linux/thrspinlock.s
> <classlib>/modules/luni/src/main/native/thread/linux/thrhelp.s
> or
> <classlib>/modules/luni/src/main/native/thread/windows/thrspinlock.asm
> <classlib>/modules/luni/src/main/native/thread/windows/thrhelp.asm
>
> Thanks, Dmitry.
>
> 2006/7/25, Marina Goldburt <ma...@gmail.com>:
> > Hi,
> >
> > I'm interested in the task of porting classlib to the 64bit platform
> > (em64t/amd64).
> > At this moment, classlib's source structure and build system doesn't
> support
> > the diversity of platforms.
> > Let's discuss what changes have to be made to support other platforms.
> > One way is to move platform-dependent to the appropriate directory. For
> > example,
> > port--linux --ia32
> > --em64t
> > --ipf
> > makefile
> > and to add platform determination and proper files selection to the
> > makefile.
> > The other way is to select the platform-dependent code by the
> preprocessor
> > difine directives and to include the platform determination and the
> difines
> > setting to the top-level build files (unfortunatly it doesn't work with
> asm
> > files).
> >
> > Any thoughts?
> >
> > Thanks, Marina.
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [classlib] porting to other platforms
Posted by Dmitry Yershov <dm...@gmail.com>.
At first, all assembler files should be propagated to the 64bit platforms. e.g.:
<classlib>/modules/luni/src/main/native/thread/linux/thrspinlock.s
<classlib>/modules/luni/src/main/native/thread/linux/thrhelp.s
or
<classlib>/modules/luni/src/main/native/thread/windows/thrspinlock.asm
<classlib>/modules/luni/src/main/native/thread/windows/thrhelp.asm
Thanks, Dmitry.
2006/7/25, Marina Goldburt <ma...@gmail.com>:
> Hi,
>
> I'm interested in the task of porting classlib to the 64bit platform
> (em64t/amd64).
> At this moment, classlib's source structure and build system doesn't support
> the diversity of platforms.
> Let's discuss what changes have to be made to support other platforms.
> One way is to move platform-dependent to the appropriate directory. For
> example,
> port--linux --ia32
> --em64t
> --ipf
> makefile
> and to add platform determination and proper files selection to the
> makefile.
> The other way is to select the platform-dependent code by the preprocessor
> difine directives and to include the platform determination and the difines
> setting to the top-level build files (unfortunatly it doesn't work with asm
> files).
>
> Any thoughts?
>
> Thanks, Marina.
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] porting to other platforms
Posted by Marina Goldburt <ma...@gmail.com>.
The link to the patch:
http://issues.apache.org/jira/browse/HARMONY-1005
Thanks, Marina
On 7/31/06, Marina Goldburt <ma...@gmail.com> wrote:
>
> Hi,
> I've prepared a patch, that allows the classlib to be compiled and run
> under Linux/x86_64 platform.
>
> Please, review and comment it.
>
> Marina
>
>
> On 7/26/06, Paulex Yang <pa...@gmail.com> wrote:
> >
> > ICU4C already has some official 64 bits binaries download (For PPC,
> > Spark, etc)[1], and has been tested on more platforms[2], ICU4J is pure
> >
> > Java, ICU4JNI only release in source codes and also has been tested on
> > many platforms[3], so basically I think ICU library can meets our
> > requirements.
> >
> > The other issue is how we put these libraries(or builds them if
> > necessary) into our builds, the trunk/depends already has
> > subdirectories for different platforms and it should be open for
> > extension, and I suppose some extension to the build script is also
> > necessary.
> >
> > [1] http://www-306.ibm.com/software/globalization/icu/downloads.jsp
> > [2]
> >
> > http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu/readme.html?rev=release-3-4-1#HowToBuildSupported
> > [3]
> > http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu4jni/readme.html?rev=release-3-4
> >
> >
> > Marina Goldburt wrote:
> > > The other problem to port classllib to 64-bit platforms is that the
> > > classlib
> > > depends on the icu* binaries. We have the binaries only for ia32
> > > platform.
> > >
> > > Are there any plans to put to svn icu* libraries for other platforms?
> > >
> > > Marina.
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
Re: [classlib] porting to other platforms
Posted by Geir Magnusson Jr <ge...@pobox.com>.
WOO!
Ok, now I just need a x86_64 setup...
geir
Marina Goldburt wrote:
> Hi,
> I've prepared a patch, that allows the classlib to be compiled and run
> under
> Linux/x86_64 platform.
>
> Please, review and comment it.
>
> Marina
>
>
> On 7/26/06, Paulex Yang <pa...@gmail.com> wrote:
>>
>> ICU4C already has some official 64 bits binaries download (For PPC,
>> Spark, etc)[1], and has been tested on more platforms[2], ICU4J is pure
>> Java, ICU4JNI only release in source codes and also has been tested on
>> many platforms[3], so basically I think ICU library can meets our
>> requirements.
>>
>> The other issue is how we put these libraries(or builds them if
>> necessary) into our builds, the trunk/depends already has
>> subdirectories for different platforms and it should be open for
>> extension, and I suppose some extension to the build script is also
>> necessary.
>>
>> [1] http://www-306.ibm.com/software/globalization/icu/downloads.jsp
>> [2]
>>
>> http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu/readme.html?rev=release-3-4-1#HowToBuildSupported
>>
>> [3]
>>
>> http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu4jni/readme.html?rev=release-3-4
>>
>>
>> Marina Goldburt wrote:
>> > The other problem to port classllib to 64-bit platforms is that the
>> > classlib
>> > depends on the icu* binaries. We have the binaries only for ia32
>> > platform.
>> >
>> > Are there any plans to put to svn icu* libraries for other platforms?
>> >
>> > Marina.
>> >
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] porting to other platforms
Posted by Marina Goldburt <ma...@gmail.com>.
Hi,
I've prepared a patch, that allows the classlib to be compiled and run under
Linux/x86_64 platform.
Please, review and comment it.
Marina
On 7/26/06, Paulex Yang <pa...@gmail.com> wrote:
>
> ICU4C already has some official 64 bits binaries download (For PPC,
> Spark, etc)[1], and has been tested on more platforms[2], ICU4J is pure
> Java, ICU4JNI only release in source codes and also has been tested on
> many platforms[3], so basically I think ICU library can meets our
> requirements.
>
> The other issue is how we put these libraries(or builds them if
> necessary) into our builds, the trunk/depends already has
> subdirectories for different platforms and it should be open for
> extension, and I suppose some extension to the build script is also
> necessary.
>
> [1] http://www-306.ibm.com/software/globalization/icu/downloads.jsp
> [2]
>
> http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu/readme.html?rev=release-3-4-1#HowToBuildSupported
> [3]
>
> http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu4jni/readme.html?rev=release-3-4
>
> Marina Goldburt wrote:
> > The other problem to port classllib to 64-bit platforms is that the
> > classlib
> > depends on the icu* binaries. We have the binaries only for ia32
> > platform.
> >
> > Are there any plans to put to svn icu* libraries for other platforms?
> >
> > Marina.
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [classlib] porting to other platforms
Posted by Paulex Yang <pa...@gmail.com>.
ICU4C already has some official 64 bits binaries download (For PPC,
Spark, etc)[1], and has been tested on more platforms[2], ICU4J is pure
Java, ICU4JNI only release in source codes and also has been tested on
many platforms[3], so basically I think ICU library can meets our
requirements.
The other issue is how we put these libraries(or builds them if
necessary) into our builds, the trunk/depends already has
subdirectories for different platforms and it should be open for
extension, and I suppose some extension to the build script is also
necessary.
[1] http://www-306.ibm.com/software/globalization/icu/downloads.jsp
[2]
http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu/readme.html?rev=release-3-4-1#HowToBuildSupported
[3]
http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu4jni/readme.html?rev=release-3-4
Marina Goldburt wrote:
> The other problem to port classllib to 64-bit platforms is that the
> classlib
> depends on the icu* binaries. We have the binaries only for ia32
> platform.
>
> Are there any plans to put to svn icu* libraries for other platforms?
>
> Marina.
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] porting to other platforms
Posted by Rana Dasgupta <rd...@gmail.com>.
Not intending to digress, but we need to discuss what are the platforms of
choice for Harmony...which are the first tier and second tier h/w and O/s's
that we would like to port/build/test/benchmark/performance tune on before
starting porting projects.
We also need to define at least for the compilers, a minimal machine model (
h/w, OS )that we want to be compatible with. This also impacts porting work.
Eg., right now, the way Jitrino floating point is implemented, it assumes a
pentium 4. We need to do more work if we want to be PIII compatible.
Would it be possible to get some opinions on this before we just start
porting projects in a somewhat isolated fashion?
Thanks,
Rana
On 7/25/06, Marina Goldburt <ma...@gmail.com> wrote:
>
> The other problem to port classllib to 64-bit platforms is that the
> classlib
> depends on the icu* binaries. We have the binaries only for ia32 platform.
>
> Are there any plans to put to svn icu* libraries for other platforms?
>
> Marina.
>
>
Re: [classlib] porting to other platforms
Posted by Marina Goldburt <ma...@gmail.com>.
The other problem to port classllib to 64-bit platforms is that the classlib
depends on the icu* binaries. We have the binaries only for ia32 platform.
Are there any plans to put to svn icu* libraries for other platforms?
Marina.
Re: [classlib] porting to other platforms
Posted by Paulex Yang <pa...@gmail.com>.
Marina Goldburt wrote:
>> On 7/25/06, Paulex Yang <pa...@gmail.com> wrote:mm...
>
>> Do you mean VM or classlib? I'm not familiar with current VM(DRL,
>> JCHEVM, BootJVM...)'s structure, but for classlib, IIRC we have
>> discussed these issue before, and seems the agreement is to layout them
>> into directories,
>
>> For example, the LUNI module has platform dependent natives, while
>> Security has platform dependent java codes, they are layout as this:
>
>> src -- main -- java(native) -- share
> -- linux
> -- windows
>
> The question is what to do if the code depends not only on an operating
> system but on
> a machine architecture too. (em64t,ipf ...)
I see, personally I"m fine to add architecture as operation systems'
subdirectory if necessary.
>
> And it is only about the classlib. The DRLVM has possibilities to add
> architecture dependent code. (I don't know about other vms - I'm not
> familiar with them too)
>
> Marina
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] porting to other platforms
Posted by Marina Goldburt <ma...@gmail.com>.
>On 7/25/06, Paulex Yang <pa...@gmail.com> wrote:mm...
>Do you mean VM or classlib? I'm not familiar with current VM(DRL,
>JCHEVM, BootJVM...)'s structure, but for classlib, IIRC we have
>discussed these issue before, and seems the agreement is to layout them
>into directories,
>For example, the LUNI module has platform dependent natives, while
>Security has platform dependent java codes, they are layout as this:
>src -- main -- java(native) -- share
-- linux
-- windows
The question is what to do if the code depends not only on an operating
system but on
a machine architecture too. (em64t,ipf ...)
And it is only about the classlib. The DRLVM has possibilities to add
architecture dependent code. (I don't know about other vms - I'm not
familiar with them too)
Marina
Re: [classlib] porting to other platforms
Posted by Paulex Yang <pa...@gmail.com>.
Marina Goldburt wrote:
> Hi,
>
> I'm interested in the task of porting classlib to the 64bit platform
> (em64t/amd64).
Thanks you! Welcome!
> At this moment, classlib's source structure and build system doesn't
> support
> the diversity of platforms.
hmm...
Do you mean VM or classlib? I'm not familiar with current VM(DRL,
JCHEVM, BootJVM...)'s structure, but for classlib, IIRC we have
discussed these issue before, and seems the agreement is to layout them
into directories,
For example, the LUNI module has platform dependent natives, while
Security has platform dependent java codes, they are layout as this:
src -- main -- java(native) -- share
-- linux
-- windows
> Let's discuss what changes have to be made to support other platforms.
> One way is to move platform-dependent to the appropriate directory. For
> example,
> port--linux --ia32
> --em64t
> --ipf
> makefile
> and to add platform determination and proper files selection to the
> makefile.
> The other way is to select the platform-dependent code by the
> preprocessor
> difine directives and to include the platform determination and the
> difines
> setting to the top-level build files (unfortunatly it doesn't work
> with asm
> files).
>
> Any thoughts?
>
> Thanks, Marina.
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org