V8 import to QtBase

[Thiago Macieira]

I see that V8 is imported into QtBase now. However, this means that many
platforms will no longer build now.

I see that V8 has MIPS support, but that isn't enabled on the v8.pro file. It's
an easy fix. But even then, V8 won't compile on MIPS -- apparently commit
9365e5fb54f3c6fdd07cab1743056a4df0403372 introduced changes which aren't
reflected on that platform.

Since there was no announcement of platform support dropping, can I assume
that the people who imported V8 will make sure QtBase at least compiles, even
if some functionality is disabled, on Sparc, MIPS and IA-64? By the time of
the feature freeze.

[l***@nokia.com]

Hi Thiago,

There's a -no-v8 configure option you can use. That should make qtbase
compile on the platforms you mentioned.

Cheers,
Lars

Post by Thiago Macieira
I see that V8 is imported into QtBase now. However, this means that many
platforms will no longer build now.
I see that V8 has MIPS support, but that isn't enabled on the v8.pro file. It's
an easy fix. But even then, V8 won't compile on MIPS -- apparently commit
9365e5fb54f3c6fdd07cab1743056a4df0403372 introduced changes which aren't
reflected on that platform.
Since there was no announcement of platform support dropping, can I assume
that the people who imported V8 will make sure QtBase at least compiles, even
if some functionality is disabled, on Sparc, MIPS and IA-64? By the time of
the feature freeze.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Thiago Macieira]

Post by l***@nokia.com
Hi Thiago,
There's a -no-v8 configure option you can use. That should make qtbase
compile on the platforms you mentioned.

I'll try that.

I managed to compile the ARM simulator on both i386 and MIPS. To compile the
simulator on i386, a very small change is necessary on the v8.pri file.

To compile on MIPS, it's again a very small change in isolate.h (the "class
HashMap" forward-definition is around #ifdefs that don't match the #ifdefs
around its use).

I should point out that V8 supports MIPS *little* endian (mipsel). My Yocto
standard build for MIPS is *big* endian (mipseb), which doesn't seem to be
supported either. So I believe we can add MIPSEB to the list of missing
targets.

I also tried to compile the ARM simulator on x86-64 and it failed. I'll
investigate more.

[Thiago Macieira]

Post by Thiago Macieira

Post by l***@nokia.com
There's a -no-v8 configure option you can use. That should make qtbase
compile on the platforms you mentioned.

I'll try that.

I've tried and it doesn't work. When running configure -no-v8 (see full args
below), I get:

...
QtTest: created version header <srcbase>/src/testlib/qttestversion.h
QtDBus: created version header <srcbase>/src/dbus/qtdbusversion.h
Project ERROR: Couldn't detect supported architecture (ia64/). Currently
supported architectures are: x64, x86 and arm
1291 projects found.

Creating makefiles. Please wait...
for /home/thiago/src/qt/qt5/qtbase/src/sql/sql.pro
for /home/thiago/src/qt/qt5/qtbase/src/tools/moc/moc.pro
for /home/thiago/src/qt/qt5/qtbase/src/gui/gui.pro
for /home/thiago/src/qt/qt5/qtbase/src/corelib/corelib.pro
for /home/thiago/src/qt/qt5/qtbase/src/v8/v8.pro
Project ERROR: Couldn't detect supported architecture (ia64/ia64). Currently
supported architectures are: x64, x86 and arm
for /home/thiago/src/qt/qt5/qtbase/src/testlib/testlib.pro
for /home/thiago/src/qt/qt5/qtbase/src/opengl/opengl.pro
...
for /home/thiago/src/qt/qt5/qtbase/src/src.pro
Project ERROR: Couldn't detect supported architecture (ia64/). Currently
supported architectures are: x64, x86 and arm
for /home/thiago/src/qt/qt5/qtbase/tests/manual/qcursor/qcursor.pro
...

The first "Project ERROR" comes when configure runs:
QTDIR="$outpath" "$outpath/bin/qmake" -spec "$XQMAKESPEC"
"${relpath}/qtbase.pro" -o "$mkfile"

This error comes from src/v8/v8.pri, and the "backtrace" of includes is:
src/v8/v8.pri
src/v8/v8.pro line 24: include(v8.pri)
src/src.pro line 97: SUB_TEMPLATE = $$list($$fromfile($$subpro, TEMPLATE))

Clearly SRC_SUBDIRS contains "v8", which indicates that QT_CONFIG does not
contain "no-v8" (see src.pro line 11)

Looking at configure, around line 7641, the conditional is inverted. It adds
"v8" to QT_CONFIG if is enabled, while src.pro searches for "no-v8".

If I correct src.pro line 11 to the proper conditional (instead of the double
negative), configure finishes without error. I'll let you know if this compiles.

[Thiago Macieira]

Post by Thiago Macieira
If I correct src.pro line 11 to the proper conditional (instead of the
double negative), configure finishes without error. I'll let you know if
this compiles.

Ok, it compiled with -no-gui -no-v8 on IA-64 and it compiled with -no-v8 on
MIPS.

So the -no-v8 option seems to work for QtBase.

My suggested course of action is therefore:

1) immediately fix src.pro line 11
2) add a configure-time check for enabling or disabling V8.
3) withhold any and all mandatory uses of V8 inside Qt Base. The module must
compile with the same API until further decision.
4) restore QtWebKit functionality on MIPS by featture-freeze (MIPS is heavily
used in the set-top-box market, where Qt and QtWebKit are quite important)

In order to determine if V8 can be made a mandatory component of Qt, we need
to discuss the fate of the following platforms:
MIPS 32-bit big-endian
MIPS64 (both endians)
Sparc 32- and 64-bit (big endian)
PowerPC / POWER6 32- and 64-bit (big endian)
IA-64 (both endians)
SH4 and others


The following are the guidelines I suggest:
- Qt Base must always compile on those platforms, with no API missing
(that means, we can't use V8's regular expression engine until the matter
is settled)

- Qt as a whole must work as expected on all supported platforms. The term
"as expected" is loosely defined to mean "what one expects to do on those
platforms".

- Modules other than Qt Base may elect not to support some platforms where
they are not very relevant. Dropping of *current* support must be announced
and discussed, with the community given ample time to react, including time
to develop code before the feature freeze (meaning: *after* the new
repository is live). The correct thing to do would be to give time before
the merging, but we've jumped the gun there.

If QtDeclarative or QtWebKit want to mandate the use of V8, they can, provided
they announce and discuss as I noted above. Neither module needs to be
supported on all platforms -- only where they are relevant.

In QtDeclarative's particular case, this exception expires when QtWidget moves
from Done to Deprecated. QtWebKit would be in the same situation if HTML5 were
to become the de-facto way of doing desktop UIs.


Note I managed to compile the ARM simulator on the MIPS target after modifying
the source code, but I have no way of testing if it works. I will try to do
the same for IA-64 ILP32 little-endian and see if the test runs. If the
simulator works, 32-bit little-endian platforms are probably safe. That leaves
the 64-bit as well as 32-bit big-endian platforms to be tested.

[Thiago Macieira]

Post by Thiago Macieira
Note I managed to compile the ARM simulator on the MIPS target after
modifying the source code, but I have no way of testing if it works. I
will try to do the same for IA-64 ILP32 little-endian and see if the test
runs. If the simulator works, 32-bit little-endian platforms are probably
safe. That leaves the 64-bit as well as 32-bit big-endian platforms to be
tested.

Failed. My system has no ILP32 libraries to link against. I can't compile Qt.

[l***@nokia.com]

Hi Thiago,

I disagree to some extent, see below.

Post by Thiago Macieira

Post by Thiago Macieira
If I correct src.pro line 11 to the proper conditional (instead of the
double negative), configure finishes without error. I'll let you know if
this compiles.

Ok, it compiled with -no-gui -no-v8 on IA-64 and it compiled with -no-v8 on
MIPS.
So the -no-v8 option seems to work for QtBase.
1) immediately fix src.pro line 11

Yes, that's a plain old bug...

Post by Thiago Macieira
2) add a configure-time check for enabling or disabling V8.
3) withhold any and all mandatory uses of V8 inside Qt Base. The module must
compile with the same API until further decision.

We'll work on getting the ARM simulator that built into V8 working on all
platforms. That should resolve the feature parity problem, but performance
might not be the best everywhere.

Post by Thiago Macieira
4) restore QtWebKit functionality on MIPS by featture-freeze (MIPS is heavily
used in the set-top-box market, where Qt and QtWebKit are quite important)

If there is someone that is willing to do the work, I'm all for it. But it
doesn't happen by itself.

Post by Thiago Macieira
In order to determine if V8 can be made a mandatory component of Qt, we need
MIPS 32-bit big-endian
MIPS64 (both endians)
Sparc 32- and 64-bit (big endian)
PowerPC / POWER6 32- and 64-bit (big endian)
IA-64 (both endians)
SH4 and others

95% of Qt users are using it on x86/x64 or ARM. I am not very tempted by
the idea of holding these 95% back to fully support processors that .1% of
our users use.

With open governance, it can't be the project's goal to stay on a least
common denominator. We need to move ahead and create the best possible
platform if we want to stay relevant.

It's up to the people that have an interest in SH4 or IA-64 to help
provide full support for that platform. If nobody steps up, it will at
some point not be supported anymore.

Let's also not forget that Qt 4.8 is out there and working nicely. If some
of the above platforms follow a bit later with working fully on Qt 5 it's
not the end of the world.

Post by Thiago Macieira
- Qt Base must always compile on those platforms, with no API missing
(that means, we can't use V8's regular expression engine until the matter
is settled)

We can and should use it IMO. The reason is that this is a switch that
would also change the default syntax from Qt own syntax to a JS compliant
syntax. I don't want to do this in a minor release.

Post by Thiago Macieira
- Qt as a whole must work as expected on all supported platforms. The term
"as expected" is loosely defined to mean "what one expects to do on those
platforms".
- Modules other than Qt Base may elect not to support some platforms where
they are not very relevant. Dropping of *current* support must be announced
and discussed, with the community given ample time to react, including time
to develop code before the feature freeze (meaning: *after* the new
repository is live). The correct thing to do would be to give time before
the merging, but we've jumped the gun there.

I remember that you were part of many of the discussions. The move to V8
was also something I said in May already when announcing Qt 5. So one
can't really say that it wasn't announced.

Post by Thiago Macieira
If QtDeclarative or QtWebKit want to mandate the use of V8, they can, provided
they announce and discuss as I noted above. Neither module needs to be
supported on all platforms -- only where they are relevant.
In QtDeclarative's particular case, this exception expires when QtWidget moves
from Done to Deprecated. QtWebKit would be in the same situation if HTML5 were
to become the de-facto way of doing desktop UIs.
Note I managed to compile the ARM simulator on the MIPS target after modifying
the source code, but I have no way of testing if it works. I will try to do
the same for IA-64 ILP32 little-endian and see if the test runs. If the
simulator works, 32-bit little-endian platforms are probably safe. That leaves
the 64-bit as well as 32-bit big-endian platforms to be tested.

The simulator should work on all platforms, and it's a way to get the full
feature set up and running. But it will most likely not be the most
performant thing on earth. But I think we should wait and look at some
benchmarks of it first (I'm trying to get some numbers).

Cheers,
Lars

[Kent Hansen]

Post by l***@nokia.com
Hi Thiago,
I disagree to some extent, see below.

Post by Thiago Macieira

Post by Thiago Macieira
If I correct src.pro line 11 to the proper conditional (instead of the
double negative), configure finishes without error. I'll let you know if
this compiles.

Ok, it compiled with -no-gui -no-v8 on IA-64 and it compiled with -no-v8 on
MIPS.
So the -no-v8 option seems to work for QtBase.
1) immediately fix src.pro line 11

Yes, that's a plain old bug...

The fix is in staging now.
Additionally, the architecture detection in v8.pri is still a bit flaky
because QT_ARCH isn't set correctly when v8.pro is evaluated from within
src.pro -- see https://bugreports.qt.nokia.com/browse/QTBUG-21224.

Post by l***@nokia.com

Post by Thiago Macieira
2) add a configure-time check for enabling or disabling V8.
3) withhold any and all mandatory uses of V8 inside Qt Base. The module must
compile with the same API until further decision.

We'll work on getting the ARM simulator that built into V8 working on all
platforms. That should resolve the feature parity problem, but performance
might not be the best everywhere.

Yup.

Kent

[Thiago Macieira]

Post by Kent Hansen
Additionally, the architecture detection in v8.pri is still a bit flaky
because QT_ARCH isn't set correctly when v8.pro is evaluated from within
src.pro -- see https://bugreports.qt.nokia.com/browse/QTBUG-21224.

configure and configure.exe need to be changed to use real architectures instead
of "windows". It would also be a good idea to detect the architecture from the
executables the compiler generates, instead of from uname.

In the case of Mac, where the compiler can generate multi-arch, there's no
support in qmake to have arch-dependent files. So V8 cannot be built in "fat
binary" mode by qmake at all.

Post by Kent Hansen

Post by l***@nokia.com

Post by Thiago Macieira
2) add a configure-time check for enabling or disabling V8.
3) withhold any and all mandatory uses of V8 inside Qt Base. The module must
compile with the same API until further decision.

We'll work on getting the ARM simulator that built into V8 working on all
platforms. That should resolve the feature parity problem, but performance
might not be the best everywhere.

Yup.

Where are you guys working on this? The current V8 repository is dated from
May. Upstream must have made improvements and fixes.

[Kent Hansen]

Post by Thiago Macieira
Where are you guys working on this? The current V8 repository is dated from
May. Upstream must have made improvements and fixes.

There's a rebase in progress. Currently QML crashes on it because of one
or more of our QML-specific patches.

Regards,
Kent

[Thiago Macieira]

Post by Kent Hansen

Post by Thiago Macieira
Where are you guys working on this? The current V8 repository is dated from
May. Upstream must have made improvements and fixes.

There's a rebase in progress. Currently QML crashes on it because of one
or more of our QML-specific patches.

Ok, but where is it?

[Kent Hansen]

Post by Thiago Macieira

Post by Kent Hansen

Post by Thiago Macieira
Where are you guys working on this? The current V8 repository is dated from
May. Upstream must have made improvements and fixes.

There's a rebase in progress. Currently QML crashes on it because of one
or more of our QML-specific patches.

Ok, but where is it?

https://github.com/tronical/v8, v8-update branch, is Simon's latest
attempt (August 10).
https://github.com/aaronkennedy/v8, kents-v8-update, is mine (rebased
off of Simon's, August 31).
The QtV8 build needs to be adapted: http://pastebin.com/hMXJrrN7

Kent

[Thiago Macieira]

Post by l***@nokia.com

Post by Thiago Macieira
2) add a configure-time check for enabling or disabling V8.
3) withhold any and all mandatory uses of V8 inside Qt Base. The module must
compile with the same API until further decision.

We'll work on getting the ARM simulator that built into V8 working on all
platforms. That should resolve the feature parity problem, but performance
might not be the best everywhere.

That's fine.

I'm looking at it right now and the first problem I see is how to get it
running on 64-bit platforms. My idea is to keep a 32-bit "high word" in the
simulator that shadows all registers. The simulator runs with 32-bit
registers, but whenever it needs to call into host code, it needs to obtain
the high part of the 64-bit register.

Post by l***@nokia.com

Post by Thiago Macieira
4) restore QtWebKit functionality on MIPS by featture-freeze (MIPS is heavily
used in the set-top-box market, where Qt and QtWebKit are quite important)

If there is someone that is willing to do the work, I'm all for it. But it
doesn't happen by itself.

If the ARM simulator works, that's a start. Full MIPS functionality would be
preferred, considering how important Qt is on MIPS.

I suggest talking to the people who helped Netflix and the like and see if they
can help.

In any case, the provision of "don't drop until people have had time to react"
still applies.

Post by l***@nokia.com

Post by Thiago Macieira
In order to determine if V8 can be made a mandatory component of Qt, we need
MIPS 32-bit big-endian
MIPS64 (both endians)
Sparc 32- and 64-bit (big endian)
PowerPC / POWER6 32- and 64-bit (big endian)
IA-64 (both endians)
SH4 and others

95% of Qt users are using it on x86/x64 or ARM. I am not very tempted by
the idea of holding these 95% back to fully support processors that .1% of
our users use.
With open governance, it can't be the project's goal to stay on a least
common denominator. We need to move ahead and create the best possible
platform if we want to stay relevant.
It's up to the people that have an interest in SH4 or IA-64 to help
provide full support for that platform. If nobody steps up, it will at
some point not be supported anymore.

Agreed. But these people need time to do it.

Post by l***@nokia.com
Let's also not forget that Qt 4.8 is out there and working nicely. If some
of the above platforms follow a bit later with working fully on Qt 5 it's
not the end of the world.

No, but there's the danger of the temporary becoming the permanent.

Post by l***@nokia.com

Post by Thiago Macieira
- Qt Base must always compile on those platforms, with no API missing
(that means, we can't use V8's regular expression engine until the matter
is settled)

We can and should use it IMO. The reason is that this is a switch that
would also change the default syntax from Qt own syntax to a JS compliant
syntax. I don't want to do this in a minor release.

Agreed, which is why V8 regexp must work everywhere. Whatever may come out of
QtGui, QtWidgets, QtWebKit, QtDeclarative, at least QtCore needs to be
everywhere.

Post by l***@nokia.com

Post by Thiago Macieira
- Modules other than Qt Base may elect not to support some platforms where
they are not very relevant. Dropping of *current* support must be announced
and discussed, with the community given ample time to react, including time
to develop code before the feature freeze (meaning: *after* the new
repository is live). The correct thing to do would be to give time before
the merging, but we've jumped the gun there.

I remember that you were part of many of the discussions. The move to V8
was also something I said in May already when announcing Qt 5. So one
can't really say that it wasn't announced.

V8 was announced. V8 blocking the build of Qt Base and/or QtCore wasn't.

And we still don't have the repository and mailing lists. If I want to do the
work, I need to be able to discuss things and time get my patches in. Before
feature freeze.

Post by l***@nokia.com

Post by Thiago Macieira
Note I managed to compile the ARM simulator on the MIPS target after modifying
the source code, but I have no way of testing if it works. I will try to do
the same for IA-64 ILP32 little-endian and see if the test runs. If the
simulator works, 32-bit little-endian platforms are probably safe. That leaves
the 64-bit as well as 32-bit big-endian platforms to be tested.

The simulator should work on all platforms, and it's a way to get the full

It doesn't and that's the problem. The ARM simulator is supported right now on
i386 only. Not even x86-64 is supported. See above.

Post by l***@nokia.com
feature set up and running. But it will most likely not be the most
performant thing on earth. But I think we should wait and look at some
benchmarks of it first (I'm trying to get some numbers).

[Artur Souza (MoRpHeUz)]

Post by Thiago Macieira
V8 was announced. V8 blocking the build of Qt Base and/or QtCore wasn't.
And we still don't have the repository and mailing lists. If I want to do the
work, I need to be able to discuss things and time get my patches in. Before
feature freeze.

Exactly. Several people pointed this during Qt Contributor Summit:
while the mailing lists and repository are not completely open, if you
don't want to undermine Qt open governance you need to communicate
more through this mailing list. Otherwise we will end up with Qt5
being just what Nokia wants it to be (and not the community) only
because it was too late when the repositories were already open and we
didn't have the time to contribute.

Cheers,

[l***@nokia.com]

Post by Thiago Macieira

Post by l***@nokia.com

Post by Thiago Macieira
2) add a configure-time check for enabling or disabling V8.
3) withhold any and all mandatory uses of V8 inside Qt Base. The module must
compile with the same API until further decision.

We'll work on getting the ARM simulator that built into V8 working on all
platforms. That should resolve the feature parity problem, but performance
might not be the best everywhere.

That's fine.
I'm looking at it right now and the first problem I see is how to get it
running on 64-bit platforms. My idea is to keep a 32-bit "high word" in the
simulator that shadows all registers. The simulator runs with 32-bit
registers, but whenever it needs to call into host code, it needs to obtain
the high part of the 64-bit register.

Post by l***@nokia.com

Post by Thiago Macieira
4) restore QtWebKit functionality on MIPS by featture-freeze (MIPS is heavily
used in the set-top-box market, where Qt and QtWebKit are quite important)

If there is someone that is willing to do the work, I'm all for it. But it
doesn't happen by itself.

If the ARM simulator works, that's a start. Full MIPS functionality would be
preferred, considering how important Qt is on MIPS.

I agree. There's work ongoing to fully support V8 on MIPS. I'm not 100%
sure what the status is right now, but I heard it's working. That would be
the best solution to support MIPS.

Post by Thiago Macieira
I suggest talking to the people who helped Netflix and the like and see if they
can help.
In any case, the provision of "don't drop until people have had time to react"
still applies.

Post by l***@nokia.com

Post by Thiago Macieira
In order to determine if V8 can be made a mandatory component of Qt, we need
MIPS 32-bit big-endian
MIPS64 (both endians)
Sparc 32- and 64-bit (big endian)
PowerPC / POWER6 32- and 64-bit (big endian)
IA-64 (both endians)
SH4 and others

95% of Qt users are using it on x86/x64 or ARM. I am not very tempted by
the idea of holding these 95% back to fully support processors that .1% of
our users use.
With open governance, it can't be the project's goal to stay on a least
common denominator. We need to move ahead and create the best possible
platform if we want to stay relevant.
It's up to the people that have an interest in SH4 or IA-64 to help
provide full support for that platform. If nobody steps up, it will at
some point not be supported anymore.

Agreed. But these people need time to do it.

Post by l***@nokia.com
Let's also not forget that Qt 4.8 is out there and working nicely. If some
of the above platforms follow a bit later with working fully on Qt 5 it's
not the end of the world.

No, but there's the danger of the temporary becoming the permanent.

Post by l***@nokia.com

Post by Thiago Macieira
- Qt Base must always compile on those platforms, with no API missing
(that means, we can't use V8's regular expression engine until the matter
is settled)

We can and should use it IMO. The reason is that this is a switch that
would also change the default syntax from Qt own syntax to a JS compliant
syntax. I don't want to do this in a minor release.

Agreed, which is why V8 regexp must work everywhere. Whatever may come out of
QtGui, QtWidgets, QtWebKit, QtDeclarative, at least QtCore needs to be
everywhere.

Post by l***@nokia.com

Post by Thiago Macieira
- Modules other than Qt Base may elect not to support some platforms where
they are not very relevant. Dropping of *current* support must be announced
and discussed, with the community given ample time to react,

including

Post by Thiago Macieira
time
to develop code before the feature freeze (meaning: *after* the new
repository is live). The correct thing to do would be to give time before
the merging, but we've jumped the gun there.

I remember that you were part of many of the discussions. The move to V8
was also something I said in May already when announcing Qt 5. So one
can't really say that it wasn't announced.

V8 was announced. V8 blocking the build of Qt Base and/or QtCore wasn't.
And we still don't have the repository and mailing lists. If I want to do the
work, I need to be able to discuss things and time get my patches in. Before
feature freeze.

Yes, I'm painfully aware of the missing repository :(

Let's see how we manage this, but I am right now assuming that fixes for
platforms can go in for another while even after feature freeze.

Post by Thiago Macieira

Post by l***@nokia.com

Post by Thiago Macieira
Note I managed to compile the ARM simulator on the MIPS target after modifying
the source code, but I have no way of testing if it works. I will try

to

Post by Thiago Macieira
do
the same for IA-64 ILP32 little-endian and see if the test runs. If the
simulator works, 32-bit little-endian platforms are probably safe. That leaves
the 64-bit as well as 32-bit big-endian platforms to be tested.

The simulator should work on all platforms, and it's a way to get the full

It doesn't and that's the problem. The ARM simulator is supported right now on
i386 only. Not even x86-64 is supported. See above.

Hmmm... I didn't know that. I thought it was generic C++ code interpreting
ARM instructions. Kent, can you have a look?

Lars

[Kent Hansen]

Post by l***@nokia.com

Post by Thiago Macieira
If the ARM simulator works, that's a start. Full MIPS functionality would be
preferred, considering how important Qt is on MIPS.

I agree. There's work ongoing to fully support V8 on MIPS. I'm not 100%
sure what the status is right now, but I heard it's working. That would be
the best solution to support MIPS.

https://groups.google.com/forum/#!topic/fameisfame/YR6f8pA7jYc has a
recent status.
"The team doing the MIPS port] are not part of V8 team but they are
contributing their code back to main V8 repo. [...] Our main repo AFAIK
is still behind theirs in terms of MIPS support (e.g. optimizing
compiler is not yet merged)."

On a related note, I tested a trunk build of the MIPS simulator on ia32,
and it seems to be working:

scons mode=debug simulator=mips -j0 sample=shell

then run "./shell_g --print_code" and enter some JavaScript...

But like the ARM simulator, this also only works for 32-bit builds.

Post by l***@nokia.com

Post by Thiago Macieira
V8 was announced. V8 blocking the build of Qt Base and/or QtCore wasn't.

QtCore doesn't depend on V8 yet. Sure, that might be the direction we
want to go, but it doesn't do it _yet_.
I'm sorry about the (unannounced) breakage of Qt Base. I'll be doing
what I can to ensure that V8 stays "out of the way" for those who don't
need it / can't build it. Step one should be working now (when -no-v8 is
given, don't build it!); step two would be configure-time detection, as
you suggested.

Post by l***@nokia.com

Post by Thiago Macieira

Post by l***@nokia.com
The simulator should work on all platforms, and it's a way to get the full

It doesn't and that's the problem. The ARM simulator is supported right now on
i386 only. Not even x86-64 is supported. See above.

Hmmm... I didn't know that. I thought it was generic C++ code interpreting
ARM instructions. Kent, can you have a look?

Confirmed, see Thiago's later mail. Some pointers (e.g. callbacks) that
you pass through the public API are written straight to fields of JS
heap objects, and there's no provision for host pointer size being
different from target pointer size, it seems.

Regarding performance of the ARM simulator: Compared to a native build,
the slowdown on ia32 is about 150x on average for the V8 benchmarks (as
much as 250x for one, down to 15x for another).

Kent

[Thiago Macieira]

Post by Kent Hansen
https://groups.google.com/forum/#!topic/fameisfame/YR6f8pA7jYc has a
recent status.
"The team doing the MIPS port] are not part of V8 team but they are
contributing their code back to main V8 repo. [...] Our main repo AFAIK
is still behind theirs in terms of MIPS support (e.g. optimizing
compiler is not yet merged)."

That's good to know. It would be interesting to know as well how well the
simulators work on other 32-bit platforms, including each other. The easiest
access we have is to run the MIPS simulator on ARM.

I looked at the ARM code yesterday extensively and, aside from one very poor
programming practice in the source code, I don't see anything that would
prevent it from working.

The poor programming practice I found is the casting of function pointers to
different types of function pointers.

Post by Kent Hansen
QtCore doesn't depend on V8 yet. Sure, that might be the direction we
want to go, but it doesn't do it _yet_.
I'm sorry about the (unannounced) breakage of Qt Base. I'll be doing
what I can to ensure that V8 stays "out of the way" for those who don't
need it / can't build it. Step one should be working now (when -no-v8 is
given, don't build it!); step two would be configure-time detection, as
you suggested.

I know, thanks for your effort.

The reason I posted the email was because I had discussed with Lars the
possibility of using V8 in QtCore. My initial investigations have shown me
that V8 is currently not acceptable for QtCore and it will not become
acceptable by the feature freeze time.

For that reason, I recommend evaluating alternatives to QRegExp's replacement,
like using PCRE.

Note how V8 had been in use in QtDeclarative for some time and I didn't
complain. It's only when it became close to be used in QtCore that I decided
to investigate some more.

Post by Kent Hansen
Confirmed, see Thiago's later mail. Some pointers (e.g. callbacks) that
you pass through the public API are written straight to fields of JS
heap objects, and there's no provision for host pointer size being
different from target pointer size, it seems.
Regarding performance of the ARM simulator: Compared to a native build,
the slowdown on ia32 is about 150x on average for the V8 benchmarks (as
much as 250x for one, down to 15x for another).

As I said, the simulator is not meant to be used in production. It's only
meant to be used to debug the generated code and the compiler, without having
to debug on-device. It also simulates the cache functionality, by maintaining
a cache line state -- this is probably causing a major slowdown.

I spent a great deal of time yesterday trying to "invent ARM64". I managed to
modify assembler-arm.h enough to be 64-bit safe and I added an ldrptr/strptr
pair that would emit 64-bit loads and stores on 64-bit. I also managed to get
the simulator to build in 64-bit mode, using MIPS64 semantics -- registers are
64-bit in size and operations on 32-bit sign-extend to 64-bit.

Then I started looking at the code generators. To port it to 64-bit, this will
require reading everything, line by line, and decide at every "ldr" or "str"
call to see if the object being managed is an int or a pointer-sized object.
Comparing to the x86-64 equivalent helps, but isn't always obvious.

If we were to make "ARM64" or even MIPS64, it needs to be done in cooperation
with upstream, or maintainance would be an incredible nightmare.

For that reason, a p-code architecture or simple AST-runner would be
preferable, even if we can't get the benefits of an optimising compiler. I
haven't investigated the complexity of doing this, aside from seeing that each
of the three major architectures is 40k lines of code.

TBH, a generic runner might have some benefits for the project as a whole. I
can't see right now what the reference implementation is and how to validate
that the assembly is doing what it's supposed to do.

[Kent Hansen]

Post by Thiago Macieira

Post by Kent Hansen
QtCore doesn't depend on V8 yet. Sure, that might be the direction we
want to go, but it doesn't do it _yet_.
I'm sorry about the (unannounced) breakage of Qt Base. I'll be doing
what I can to ensure that V8 stays "out of the way" for those who don't
need it / can't build it. Step one should be working now (when -no-v8 is
given, don't build it!); step two would be configure-time detection, as
you suggested.

I know, thanks for your effort.

There's basic configure-time detection of v8 support now, hopefully it
does something useful.

I didn't know about the python 2 vs 3 issue that Olivier mentioned, but
found http://code.google.com/p/v8/issues/detail?id=1391. I've patched
our v8 for now (feel free to star the issue and/or add more nagging
comments).

Kent

[a***@nokia.com]

Hi,

As you noticed, V8 does not currently support Sparc, MIPS or IA-64. I believe that the MIPS port is being worked on by the V8 team, but the "implementation" that exists in the v8 branch we currently have is simply stubs with no implementation. As far as I know, there are no plans to add Sparc or IA-64 backends and doing so is considerable work.

My understanding is that V8 was shifted into qtbase so that it could be used by QtWebkit. Is QtWebkit supported on those platforms? If it is, I supposed we could continue to use JSC for them, and only enable V8 on the platforms it supports, but someone else would have to give a definitive answer.

Cheers,

Aaron

Post by Thiago Macieira
I see that V8 is imported into QtBase now. However, this means that many
platforms will no longer build now.
I see that V8 has MIPS support, but that isn't enabled on the v8.pro file. It's
an easy fix. But even then, V8 won't compile on MIPS -- apparently commit
9365e5fb54f3c6fdd07cab1743056a4df0403372 introduced changes which aren't
reflected on that platform.
Since there was no announcement of platform support dropping, can I assume
that the people who imported V8 will make sure QtBase at least compiles, even
if some functionality is disabled, on Sparc, MIPS and IA-64? By the time of
the feature freeze.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Konstantin Tokarev]

Hi,
As you noticed, V8 does not currently support Sparc, MIPS or IA-64.  I believe that the MIPS port is being worked on by the V8 team, but the "implementation" that exists in the v8 branch we currently have is simply stubs with no implementation.  As far as I know, there are no plans to add Sparc or IA-64 backends and doing so is considerable work.

The same is true for PPC and SH4...

[Konstantin Tokarev]

My understanding is that V8 was shifted into qtbase so that it could be used by QtWebkit.  Is QtWebkit supported on those platforms?  If it is, I supposed we could continue to use JSC for them, and only enable V8 on the platforms it supports, but someone else would have to give a definitive answer.

I can assure that QtWebKit 2.1.1 works fine on SH4 with JSC. 2.2 branch should bring JIT support in JSC for SH4, but we haven't tested it yet.

[Thiago Macieira]

Post by Konstantin Tokarev

Post by a***@nokia.com
My understanding is that V8 was shifted into qtbase so that it could be
used by QtWebkit. Is QtWebkit supported on those platforms? If it is, I
supposed we could continue to use JSC for them, and only enable V8 on the
platforms it supports, but someone else would have to give a definitive
answer.

I can assure that QtWebKit 2.1.1 works fine on SH4 with JSC. 2.2 branch
should bring JIT support in JSC for SH4, but we haven't tested it yet.

I also tested it back in the day on both Sparc and POWER (mkspecs solaris-g++
and aix-xlc). I can't easily test if it compiles on IA-64 as the machine I
have access to doesn't have the X11 headers installed -- it's used by an Intel
kernel hacker, who doesn't need anything but the C compiler...

I'll ask him to install the missing packages and will try.

[Olivier Goffart]

Post by Thiago Macieira
I see that V8 is imported into QtBase now. However, this means that many
platforms will no longer build now.
I see that V8 has MIPS support, but that isn't enabled on the v8.pro file.
It's an easy fix. But even then, V8 won't compile on MIPS -- apparently
commit 9365e5fb54f3c6fdd07cab1743056a4df0403372 introduced changes which
aren't reflected on that platform.
Since there was no announcement of platform support dropping, can I assume
that the people who imported V8 will make sure QtBase at least compiles,
even if some functionality is disabled, on Sparc, MIPS and IA-64? By the
time of the feature freeze.

Welcome to the new "cross-platform" definition according to nokia, that
basically mean "Ubuntu 10.4" (slightly sarcastic :-))


I also get this error while compiling v8 on my Archlinux:


Traceback (most recent call last):
File "/mnt/sda7/qtsrc/qt-5-src/qtbase/src/v8/../3rdparty/v8/tools/js2c.py",
line 380, in <module>
main()
File "/mnt/sda7/qtsrc/qt-5-src/qtbase/src/v8/../3rdparty/v8/tools/js2c.py",
line 377, in main
JS2C(source_files, [natives, natives_empty], { 'TYPE': type })
File "/mnt/sda7/qtsrc/qt-5-src/qtbase/src/v8/../3rdparty/v8/tools/js2c.py",
line 282, in JS2C
(consts, macros) = ReadMacros(ReadLines(str(s)))
File "/mnt/sda7/qtsrc/qt-5-src/qtbase/src/v8/../3rdparty/v8/tools/js2c.py",
line 190, in ReadMacros
args = map(string.strip, macro_match.group(2).split(','))
AttributeError: 'module' object has no attribute 'strip'
make[1]: *** [generated/libraries.cpp] Error 1


This is because the python program is hardcoded in the v8.pri file, and the
script js2c.py is not compatible with python 3
(on Archlinux, the version 2 of python is in /usr/bin/python2)

2 solutions:
- using configure to detect the right path to python2 (and warn if python2
was not found.), or
- port the script to the common subset of python 2 and python 3

[Thiago Macieira]

Post by Thiago Macieira
It doesn't and that's the problem. The ARM simulator is supported right
now on
i386 only. Not even x86-64 is supported. See above.

Hmmm... I didn't know that. I thought it was generic C++ code interpreting
ARM instructions. Kent, can you have a look?

It is. The problem is that the ARM instructions are 32-bit, so they can't
reference the entire 64-bit address space. E.g.:

src/3rdparty/v8/src/arm/assembler-arm-inl.h:254:49: error: cast from
'v8::internal::Address' to 'int32_t' loses precision [-fpermissive]
1) write a pseudo-processor that compiles to p-code and is executed by the
simulator only.

2) extend the MIPS code to support MIPS64 and simulate MIPS64 on 64-bit
processors

3) "invent" ARM64 (by extending ARMv7 like MIPS64 extends MIPS32) and simulate
that on 64-bit platforms

4) if all the addresses that the ARM code needs to load are in memory block
allocated by the engine, then modify the engine to be able to call back into
64-bit code and, in the process, add the "high word" part of the 32-bit
registers.

I think #4 -- my original intention -- is unlikely.

MIPS32 and MIPS64 differ only that the latter has 64-bit registers and two more
instructions ("load double" and "store double") and that 32-bit operations on
the registers clear the high word (like x86-64). Therefore, extending either
the MIPS engine to MIPS64 or the ARM engine to "ARM64" would involve extending
the register size, patching the code that loads/stores to memory pointers to
use the 64-bit operation and then adapting the simulator.

The changes wouldn't be that big. It would start by replacing int32_t with
intptr_t everywhere where a pointer is being managed and in the register file.

The advantage of MIPS64 over "ARM64" is that the instructions exist in the
ISA, so we don't have to "guess" where ARM will place the instructions in the
future. The advantage of ARM is that the code is more likely to be working at
all times, given Nokia and Google's priorities these days.

However, neither simulator is meant for efficiency. They are meant for debugging
the MIPS and ARM assemblers, so in that sense option #1 is preferable.

Given unlimited time and unlimited resources, my recommendation would be
option #1. As that is not the case, options 2 and 3 are more likely.

[Kent Hansen]

Post by Thiago Macieira

Post by Thiago Macieira
It doesn't and that's the problem. The ARM simulator is supported right now on
i386 only. Not even x86-64 is supported. See above.

Hmmm... I didn't know that. I thought it was generic C++ code interpreting
ARM instructions. Kent, can you have a look?

It is. The problem is that the ARM instructions are 32-bit, so they can't
src/3rdparty/v8/src/arm/assembler-arm-inl.h:254:49: error: cast from
'v8::internal::Address' to 'int32_t' loses precision [-fpermissive]
1) write a pseudo-processor that compiles to p-code and is executed by the
simulator only.
2) extend the MIPS code to support MIPS64 and simulate MIPS64 on 64-bit
processors
3) "invent" ARM64 (by extending ARMv7 like MIPS64 extends MIPS32) and simulate
that on 64-bit platforms
4) if all the addresses that the ARM code needs to load are in memory block
allocated by the engine, then modify the engine to be able to call back into
64-bit code and, in the process, add the "high word" part of the 32-bit
registers.
I think #4 -- my original intention -- is unlikely.
MIPS32 and MIPS64 differ only that the latter has 64-bit registers and two more
instructions ("load double" and "store double") and that 32-bit operations on
the registers clear the high word (like x86-64). Therefore, extending either
the MIPS engine to MIPS64 or the ARM engine to "ARM64" would involve extending
the register size, patching the code that loads/stores to memory pointers to
use the 64-bit operation and then adapting the simulator.
The changes wouldn't be that big. It would start by replacing int32_t with
intptr_t everywhere where a pointer is being managed and in the register file.
The advantage of MIPS64 over "ARM64" is that the instructions exist in the
ISA, so we don't have to "guess" where ARM will place the instructions in the
future. The advantage of ARM is that the code is more likely to be working at
all times, given Nokia and Google's priorities these days.
However, neither simulator is meant for efficiency. They are meant for debugging
the MIPS and ARM assemblers, so in that sense option #1 is preferable.
Given unlimited time and unlimited resources, my recommendation would be
option #1. As that is not the case, options 2 and 3 are more likely.

Great summary.
Option 2 seems the most reasonable/low-effort to me, as MIPS64 is
already an established architecture, and it doesn't differ much from
MIPS32, as you pointed out. I created
http://code.google.com/p/v8/issues/detail?id=1655 and sent a mail to the
main MIPS/V8 guy, let's see what they say.

Wish I could contribute, as I know MIPS32/64 quite well :( We do have
collaborators at Szeged university who have V8 commit rights and can
help us with this type of thing.

Kent

[Richard Moore]

TBH it seems to me that is is too much stuff for QtBase, a javascript
interpreter??!. Base implies a minimal set. For example, I'd expect to
be able to use qtbase to build a daemon for a headless server. I'm
thinking core stuff like QCoreApplication, QString possibly even the
networking modules.

Right now we don't have a forum to discuss this properly, so this list
appears to be the best we've got.

Rich.

[Konstantin Ritt]

completely agree with Richard.
I already asked at IRC but didn't get an answer - isn't it possible to
wrap V8 in a Qtish API and link to some QtV8 from declarative, webkit
or whatever?

Konstantin

Post by Richard Moore
TBH it seems to me that is is too much stuff for QtBase, a javascript
interpreter??!. Base implies a minimal set. For example, I'd expect to
be able to use qtbase to build a daemon for a headless server. I'm
thinking core stuff like QCoreApplication, QString possibly even the
networking modules.
Right now we don't have a forum to discuss this properly, so this list
appears to be the best we've got.
Rich.
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Thiago Macieira]

Post by Konstantin Ritt
I already asked at IRC but didn't get an answer - isn't it possible to
wrap V8 in a Qtish API and link to some QtV8 from declarative, webkit
or whatever?

That's exactly what is being done, minus the Qt-ish API.

The libQtV8 module doesn't have a Qt front-end API. The JS API for it would be
QtScript or something similar. We need a JS front-end API anyway to add
objects to QtDeclarative and manipulate them.

[Thiago Macieira]

Post by Richard Moore
TBH it seems to me that is is too much stuff for QtBase, a javascript
interpreter??!. Base implies a minimal set. For example, I'd expect to
be able to use qtbase to build a daemon for a headless server. I'm
thinking core stuff like QCoreApplication, QString possibly even the
networking modules.
Right now we don't have a forum to discuss this properly, so this list
appears to be the best we've got.

I'm in agreement. I wouldn't mind a JS interpreter in the base modules,
provided it worked everywhere. That was QtScript between 4.3 and 4.6. With
JSC, supporting it in multiple architectures became a maintenance burden, but
doable. With V8 it looks very daunting.

I don't mind it being inside QtBase, but we can't depend on it.

[Olivier Goffart]

Post by Richard Moore
TBH it seems to me that is is too much stuff for QtBase, a javascript
interpreter??!. Base implies a minimal set. For example, I'd expect to
be able to use qtbase to build a daemon for a headless server. I'm
thinking core stuff like QCoreApplication, QString possibly even the
networking modules.
Right now we don't have a forum to discuss this properly, so this list
appears to be the best we've got.

Do not mix qtbase and QtCore.
QtBase is a repository that contains few library such as QtCore, QtGui,
and
now, V8.
Considering that we plan to have both QtDeclarative, QtWebKit, and the
replacement for QtScript that are going to use V8, it make sens to put
this
common dependence in qtbase.

When you do your minimal deamon, you can just link against QtCore, you do
not
need V8. (you do not even need to compile it, you can pass -no-v8)

I hope this answer your concern.

[Konstantin Ritt]

Post by Thiago Macieira
That's exactly what is being done, minus the Qt-ish API.
The libQtV8 module doesn't have a Qt front-end API. The JS API for it would be
QtScript or something similar. We need a JS front-end API anyway to add
objects to QtDeclarative and manipulate them.

sounds good, then.

Post by Thiago Macieira
When you do your minimal deamon, you can just link against QtCore, you do not
need V8. (you do not even need to compile it, you can pass -no-v8)

this is something that doesn't fit into the idea of replacing
QRegExp's custom engine with V8's one (or did I misunderstood
something?).


and by the way, by a glance v8 code review I found it's RE is quite
poor on functionality - well, it's probably more than enough for JS
but it's definitely not - for Qt users (some of them at very least).
so, I voting for PCRE as a default QRegExp's engine. what else we
could use from v8 in qtcore?

regards,
Konstantin

Post by Thiago Macieira

Post by Richard Moore
TBH it seems to me that is is too much stuff for QtBase, a javascript
interpreter??!. Base implies a minimal set. For example, I'd expect to
be able to use qtbase to build a daemon for a headless server. I'm
thinking core stuff like QCoreApplication, QString possibly even the
networking modules.
Right now we don't have a forum to discuss this properly, so this list
appears to be the best we've got.

Do not mix qtbase and QtCore.
QtBase is a repository that contains few library such as QtCore, QtGui,
and
now, V8.
Considering that we plan to have both QtDeclarative, QtWebKit, and the
replacement for QtScript that are going to use V8, it make sens to put
this
common dependence in qtbase.
When you do your minimal deamon, you can just link against QtCore, you do
not
need V8. (you do not even need to compile it, you can pass -no-v8)
I hope this answer your concern.
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Thiago Macieira]

Post by Konstantin Ritt
this is something that doesn't fit into the idea of replacing
QRegExp's custom engine with V8's one (or did I misunderstood
something?).

This is why I started the thread in the first place: Lars and I had discussed
the idea of using V8's RE engine to replace QRegExp. But after investigating
V8, I came to the conclusion that this idea was not acceptable.

The advantage of that would be that the C++ and QML sides of Qt would have
access to the same RE syntax. And we wouldn't need two RE engines in memory.

PCRE looks more likely to be the replacement for QRegExp.

[l***@nokia.com]

Post by Konstantin Ritt

Post by Thiago Macieira
That's exactly what is being done, minus the Qt-ish API.
The libQtV8 module doesn't have a Qt front-end API. The JS API for it would be
QtScript or something similar. We need a JS front-end API anyway to add
objects to QtDeclarative and manipulate them.

sounds good, then.

Post by Thiago Macieira
When you do your minimal deamon, you can just link against QtCore, you do not
need V8. (you do not even need to compile it, you can pass -no-v8)

That's the current state. Question is whether this is what we want in the
long term.

Post by Konstantin Ritt
this is something that doesn't fit into the idea of replacing
QRegExp's custom engine with V8's one (or did I misunderstood
something?).

No, this is something I am considering.

I am also considering having a dependency of QtCore onto a JS engine. Now
before you all cry out loud, let me first explain this (I'll write a
separate mail).

Post by Konstantin Ritt
and by the way, by a glance v8 code review I found it's RE is quite
poor on functionality - well, it's probably more than enough for JS
but it's definitely not - for Qt users (some of them at very least).
so, I voting for PCRE as a default QRegExp's engine. what else we
could use from v8 in qtcore?

JS Regexps have pretty much the same functionality that QRegExp currently
has. So your argument that it's not good enough for Qt users doesn't hold
IMO.

There's at least one other piece I'd like to use from V8, the dtoa code.

On many non desktop platforms the total size of Qt matters, so avoiding
duplicated functionality in the stack is a good thing. It also gives
consistent behavior.

Cheers,
Lars

Post by Konstantin Ritt
regards,
Konstantin

Post by Thiago Macieira

Post by Richard Moore
TBH it seems to me that is is too much stuff for QtBase, a javascript
interpreter??!. Base implies a minimal set. For example, I'd expect to
be able to use qtbase to build a daemon for a headless server. I'm
thinking core stuff like QCoreApplication, QString possibly even the
networking modules.
Right now we don't have a forum to discuss this properly, so this list
appears to be the best we've got.

Do not mix qtbase and QtCore.
QtBase is a repository that contains few library such as QtCore, QtGui,
and
now, V8.
Considering that we plan to have both QtDeclarative, QtWebKit, and the
replacement for QtScript that are going to use V8, it make sens to put
this
common dependence in qtbase.
When you do your minimal deamon, you can just link against QtCore, you do
not
need V8. (you do not even need to compile it, you can pass -no-v8)
I hope this answer your concern.
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Kent Hansen]

Post by Konstantin Ritt
and by the way, by a glance v8 code review I found it's RE is quite
poor on functionality - well, it's probably more than enough for JS
but it's definitely not - for Qt users (some of them at very least).
so, I voting for PCRE as a default QRegExp's engine. what else we
could use from v8 in qtcore?
regards,
Konstantin

There's https://bugreports.qt.nokia.com/browse/QTBUG-20893, which I
believe is what Lars will address in that separate mail (re "I am also
considering having a dependency of QtCore onto a JS engine").

Regards,
Kent

[Richard Moore]

Post by Olivier Goffart

Post by Richard Moore
TBH it seems to me that is is too much stuff for QtBase, a javascript
interpreter??!. Base implies a minimal set. For example, I'd expect to
be able to use qtbase to build a daemon for a headless server. I'm
thinking core stuff like QCoreApplication, QString possibly even the
networking modules.
Right now we don't have a forum to discuss this properly, so this list
appears to be the best we've got.

Do not mix qtbase and QtCore.
QtBase is a repository that contains few library such as QtCore, QtGui,
and
now, V8.
Considering that we plan to have both QtDeclarative, QtWebKit, and the
replacement for QtScript that are going to use V8, it make sens to put
this
common dependence in qtbase.
When you do your minimal deamon, you can just link against QtCore, you do
not
need V8. (you do not even need to compile it, you can pass -no-v8)
I hope this answer your concern.

I'm afraid not. Once the code is packaged we'll end up with a qt-base
rpm, this will have the dependencies of everything in the qtbase
repository. That means that if someone wants to install my daemon
they'll end up pulling in everything else. The alternative would be to
have the same repo packaged multiple times with various options which
will lead to problems, for example the possibility of multiple qt-base
packages that are incompatible due to different options/feature sets.

This problem can be avoided completely by simply having another module.

The wider problem is the total lack of discussion on any public forum.
This is a much more important issue, and one that is currently being
handled terribly by the Qt team. I think people have been fairly
patient about the lack of opengov so far, but since we've now passed
the date given at QCS as being the Qt 5.0 feature freeze, it's time to
demonstrate that this is more than hot air.

Cheers

Rich.

[l***@nokia.com]

Post by Richard Moore

Post by Olivier Goffart

Post by Richard Moore
TBH it seems to me that is is too much stuff for QtBase, a javascript
interpreter??!. Base implies a minimal set. For example, I'd expect to
be able to use qtbase to build a daemon for a headless server. I'm
thinking core stuff like QCoreApplication, QString possibly even the
networking modules.
Right now we don't have a forum to discuss this properly, so this list
appears to be the best we've got.

Do not mix qtbase and QtCore.
QtBase is a repository that contains few library such as QtCore, QtGui,
and
now, V8.
Considering that we plan to have both QtDeclarative, QtWebKit, and the
replacement for QtScript that are going to use V8, it make sens to put
this
common dependence in qtbase.
When you do your minimal deamon, you can just link against QtCore, you do
not
need V8. (you do not even need to compile it, you can pass -no-v8)
I hope this answer your concern.

I'm afraid not. Once the code is packaged we'll end up with a qt-base
rpm, this will have the dependencies of everything in the qtbase
repository. That means that if someone wants to install my daemon
they'll end up pulling in everything else. The alternative would be to
have the same repo packaged multiple times with various options which
will lead to problems, for example the possibility of multiple qt-base
packages that are incompatible due to different options/feature sets.

That's not true today neither. Qt 4.x is usually packaged as a long list
of rpm/debs on all Linux distributions I know. Even if qtbase is one
repository, this doesn't mean it can't be several binary packages.

And who said the current state of qtbase is the final one? Long term I
want to split up the repository further.

But even if you have the dependency, I don't see the problem. Currently
QtCore also links against glib. Do you use any of it for your daemon?
Probably not, still nobody ever complained about it.

Post by Richard Moore
This problem can be avoided completely by simply having another module.
The wider problem is the total lack of discussion on any public forum.
This is a much more important issue, and one that is currently being
handled terribly by the Qt team. I think people have been fairly
patient about the lack of opengov so far, but since we've now passed
the date given at QCS as being the Qt 5.0 feature freeze, it's time to
demonstrate that this is more than hot air.

I am as frustrated as you about it not being out yet (and so are many
people inside Nokia). While I can't tell you details of why this takes so
long, I can assure you that this was in this case not really Nokia's
fault.

Cheers,
Lars

[Kent Hansen]

(Hmm, this mail hasn't appeared on the list yet, resending...)

Post by Thiago Macieira

Post by Thiago Macieira
It doesn't and that's the problem. The ARM simulator is supported right now on
i386 only. Not even x86-64 is supported. See above.

Hmmm... I didn't know that. I thought it was generic C++ code interpreting
ARM instructions. Kent, can you have a look?

It is. The problem is that the ARM instructions are 32-bit, so they can't
src/3rdparty/v8/src/arm/assembler-arm-inl.h:254:49: error: cast from
'v8::internal::Address' to 'int32_t' loses precision [-fpermissive]
1) write a pseudo-processor that compiles to p-code and is executed by the
simulator only.
2) extend the MIPS code to support MIPS64 and simulate MIPS64 on 64-bit
processors
3) "invent" ARM64 (by extending ARMv7 like MIPS64 extends MIPS32) and simulate
that on 64-bit platforms
4) if all the addresses that the ARM code needs to load are in memory block
allocated by the engine, then modify the engine to be able to call back into
64-bit code and, in the process, add the "high word" part of the 32-bit
registers.
I think #4 -- my original intention -- is unlikely.
MIPS32 and MIPS64 differ only that the latter has 64-bit registers and two more
instructions ("load double" and "store double") and that 32-bit operations on
the registers clear the high word (like x86-64). Therefore, extending either
the MIPS engine to MIPS64 or the ARM engine to "ARM64" would involve extending
the register size, patching the code that loads/stores to memory pointers to
use the 64-bit operation and then adapting the simulator.
The changes wouldn't be that big. It would start by replacing int32_t with
intptr_t everywhere where a pointer is being managed and in the register file.
The advantage of MIPS64 over "ARM64" is that the instructions exist in the
ISA, so we don't have to "guess" where ARM will place the instructions in the
future. The advantage of ARM is that the code is more likely to be working at
all times, given Nokia and Google's priorities these days.
However, neither simulator is meant for efficiency. They are meant for debugging
the MIPS and ARM assemblers, so in that sense option #1 is preferable.
Given unlimited time and unlimited resources, my recommendation would be
option #1. As that is not the case, options 2 and 3 are more likely.

Great summary.
Option 2 seems the most reasonable/low-effort to me, as MIPS64 is
already an established architecture, and it doesn't differ much from
MIPS32, as you pointed out. I created
http://code.google.com/p/v8/issues/detail?id=1655 and sent a mail to the
main MIPS/V8 guy, let's see what they say.

Wish I could contribute, as I know MIPS32/64 quite well :( We do have
collaborators at Szeged university who have V8 commit rights and can
help us with this type of thing.

Kent

[Kent Hansen]

(What's up with this list blocking my emails? _Third_ try...)

Post by Thiago Macieira

Post by Thiago Macieira
It doesn't and that's the problem. The ARM simulator is supported right now on
i386 only. Not even x86-64 is supported. See above.

Hmmm... I didn't know that. I thought it was generic C++ code interpreting
ARM instructions. Kent, can you have a look?

It is. The problem is that the ARM instructions are 32-bit, so they can't
src/3rdparty/v8/src/arm/assembler-arm-inl.h:254:49: error: cast from
'v8::internal::Address' to 'int32_t' loses precision [-fpermissive]

[...]

Great summary.
Option 2 seems the most reasonable/low-effort to me, as MIPS64 is
already an established architecture, and it doesn't differ much from
MIPS32, as you pointed out. I created
http://code.google.com/p/v8/issues/detail?id=1655 and sent a mail to the
main MIPS/V8 guy, let's see what they say.

Wish I could contribute, as I know MIPS32/64 quite well :( We do have
collaborators at Szeged university who have V8 commit rights and can
help us with this type of thing.

Kent

[Konstantin Ritt]

Post by Kent Hansen
(What's up with this list blocking my emails? _Third_ try...)

Post by Thiago Macieira

Post by Thiago Macieira
It doesn't and that's the problem. The ARM simulator is supported right now on
i386 only. Not even x86-64 is supported. See above.

Hmmm... I didn't know that. I thought it was generic C++ code interpreting
ARM instructions. Kent, can you have a look?

It is. The problem is that the ARM instructions are 32-bit, so they can't
src/3rdparty/v8/src/arm/assembler-arm-inl.h:254:49: error: cast from
'v8::internal::Address' to 'int32_t' loses precision [-fpermissive]

[...]
Great summary.
Option 2 seems the most reasonable/low-effort to me, as MIPS64 is
already an established architecture, and it doesn't differ much from
MIPS32, as you pointed out. I created
http://code.google.com/p/v8/issues/detail?id=1655 and sent a mail to the
main MIPS/V8 guy, let's see what they say.
Wish I could contribute, as I know MIPS32/64 quite well :( We do have
collaborators at Szeged university who have V8 commit rights and can
help us with this type of thing.
Kent
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

appeared 3 times so far :)