Re: [webkit-dev] x32 support of JavaScriptCore
Thanks for the suggestions, Kenneth. I'm refining the code and trying to enable the last major component - the low level interpreter for x32. Yes it's ideal if we can upstream the code, and as you mentioned, keep maintaining it. The buildbot is a good idea while we are still way far from it - it requires a mature x32 system which at least supports all of the things that a WebKit port depends on. I know there're efforts porting Gentoo and Fedora to x32 - we may depend on each other. Currently I'm testing the JSC shell only. Though I use the EFL port, I eliminated most of the unnecessary dependencies on EFL libraries to run the JSC shell, so that I don't need to put efforts on compiling and enabling those dependencies for x32 at current stage. Thanks, -Yuqiang -Original Message- From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] Sent: 2012年10月11日 5:51 To: Xian, Yuqiang Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] x32 support of JavaScriptCore Hi, I don't think another branch on webkit.org will help you much; then you can as well have a branch anywhere. If you want this code to be well tested and maintained, you need to get it upstream (through all the review process) and promise that you have resources to keep maintaining it. It will also be an advantage if we can get a buildbot running this exact configuration, so that others can make sure they don't break your code. I think that whether the community will accept it upstream depends much about your commitment and the quality of the code, as well as how well you interact with the community during the reviews. Which port of WebKit is you currently using for testing? Cheers Kenneth On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang wrote: > Hi, > > > > As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64 > with 32-bit pointer size. It tries to leverage the advantage of more > registers and IP relative addressing from x64 and the advantage of smaller > memory footprint from IA32. You can find more details of the x32 ABI here: > https://sites.google.com/site/x32abi/. > > > > The Linux kernel supports x32 since 3.4, and the commonly used development > tools and libraries are getting in the x32 support. Also more details about > current status is available in the above link. > > > > Now back to WebKit. In theory most part of the WebKit code should be fine > (or require less efforts) to support x32, if they’re pure C++ code and can > be compiled with the x32 toolchain. The major challenge is the JIT compiler > in the JavaScript engine (and the low level interpreter) and some > hand-written assembly code. So I’m currently working on enabling the x32 > support of JavaScriptCore, the WebKit JavaScript engine, to try to remove > the major obstacle. My current status is that I have enabled the baseline > JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore > tests and the 3 major benchmarks. > > > > I’m posting this message in order to seek for some advices on how we should > have our work shared to more people. I understand that it’s not very > appropriate to try to get it into current WebKit trunk considering current > x32 support status in major systems and the lack of maintenance in upstream, > but we want to keep it synchronized with the newest changes of the WebKit > code. So is it possible for us to maintain the code in a separate branch > hosted at the WebKit server? > > > > Any suggestions are appreciated. > > > > Thanks, -Yuqiang > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4093 0598 / E-mail kenneth at webkit.org ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] x32 support of JavaScriptCore
Just out of curiosity, how much code modifications are required? I read the ABI documentation the link you attached, and "x32" is a regular 64 bit mode, except it seems to me that the global descriptor table is tweaked to store the same descriptors for all 4G address spaces, so the upper 32 bit is basically ignored when you access a memory address. It is called Small Code Model or something. I suspect the changes in the JIT code are minimal. Regards, Zoltan > Thanks for the suggestions, Kenneth. > > I'm refining the code and trying to enable the last major component - the > low level interpreter for x32. > Yes it's ideal if we can upstream the code, and as you mentioned, keep > maintaining it. The buildbot is a good idea while we are still way far > from it - it requires a mature x32 system which at least supports all of > the things that a WebKit port depends on. I know there're efforts porting > Gentoo and Fedora to x32 - we may depend on each other. > > Currently I'm testing the JSC shell only. Though I use the EFL port, I > eliminated most of the unnecessary dependencies on EFL libraries to run > the JSC shell, so that I don't need to put efforts on compiling and > enabling those dependencies for x32 at current stage. > > Thanks, -Yuqiang > > -Original Message- > From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] > Sent: 2012年10月11日 5:51 > To: Xian, Yuqiang > Cc: webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] x32 support of JavaScriptCore > > Hi, > > I don't think another branch on webkit.org will help you much; then > you can as well have a branch anywhere. > > If you want this code to be well tested and maintained, you need to > get it upstream (through all the review process) and promise that you > have resources to keep maintaining it. It will also be an advantage if > we can get a buildbot running this exact configuration, so that others > can make sure they don't break your code. > > I think that whether the community will accept it upstream depends > much about your commitment and the quality of the code, as well as how > well you interact with the community during the reviews. > > Which port of WebKit is you currently using for testing? > > Cheers > Kenneth > > > On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang > wrote: >> Hi, >> >> >> >> As you may already know there’s a new x32 ABI – a 32-bit psABI for >> x86-64 >> with 32-bit pointer size. It tries to leverage the advantage of more >> registers and IP relative addressing from x64 and the advantage of >> smaller >> memory footprint from IA32. You can find more details of the x32 ABI >> here: >> https://sites.google.com/site/x32abi/. >> >> >> >> The Linux kernel supports x32 since 3.4, and the commonly used >> development >> tools and libraries are getting in the x32 support. Also more details >> about >> current status is available in the above link. >> >> >> >> Now back to WebKit. In theory most part of the WebKit code should be >> fine >> (or require less efforts) to support x32, if they’re pure C++ code and >> can >> be compiled with the x32 toolchain. The major challenge is the JIT >> compiler >> in the JavaScript engine (and the low level interpreter) and some >> hand-written assembly code. So I’m currently working on enabling the >> x32 >> support of JavaScriptCore, the WebKit JavaScript engine, to try to >> remove >> the major obstacle. My current status is that I have enabled the >> baseline >> JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the >> JavaScriptCore >> tests and the 3 major benchmarks. >> >> >> >> I’m posting this message in order to seek for some advices on how we >> should >> have our work shared to more people. I understand that it’s not very >> appropriate to try to get it into current WebKit trunk considering >> current >> x32 support status in major systems and the lack of maintenance in >> upstream, >> but we want to keep it synchronized with the newest changes of the >> WebKit >> code. So is it possible for us to maintain the code in a separate >> branch >> hosted at the WebKit server? >> >> >> >> Any suggestions are appreciated. >> >> >> >> Thanks, -Yuqiang >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev >> > > > > -- > Kenneth Rohde Christiansen > Senior Engineer, WebKit, Qt, EFL > Phone +45 4093 0598 / E-mail kenneth at webkit.org > > ﹆﹆﹆ > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] x32 support of JavaScriptCore
On X32, the size of a pointer or a "long" integer is 4 bytes instead of 8 bytes on X64, while the register size is still 8 bytes. In JavaScriptCore implementation for X64, it assumes that the JSValue size is same to the pointer size, and thus EncodedJSValue is simply type defined as a "void*". In the JIT compiler, we also take this assumption and invoke the same macro assembler interface for both JSValue and pointer operands. So the primary task for x32 support is to differentiate the operations on pointers from the operations on JSValues, and let them invoking different macro assembler interfaces. For example, we now use the interface of "loadPtr" to load either a pointer or a JSValue, and we need to switch to using "loadPtr" to load a pointer and some new "load64" interface to load a JSValue. The major modification I made is to introduce the "*64" interfaces in the MacroAssembler, make the "*Ptr" interfaces platform dependent implemented (one for X32 and the other for X64), and go through all the JIT compiler code to identify which interfaces should be used. Also, the calling convention needs to be cared. For example on X64 you may need two registers to pass or return a structure with two pointer size members, while on X32 those two members are placed in one register. Thanks, -Yuqiang -Original Message- From: Zoltan Herczeg [mailto:zherc...@webkit.org] Sent: 2012年10月11日 15:43 To: Xian, Yuqiang Cc: Kenneth Rohde Christiansen; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] x32 support of JavaScriptCore Just out of curiosity, how much code modifications are required? I read the ABI documentation the link you attached, and "x32" is a regular 64 bit mode, except it seems to me that the global descriptor table is tweaked to store the same descriptors for all 4G address spaces, so the upper 32 bit is basically ignored when you access a memory address. It is called Small Code Model or something. I suspect the changes in the JIT code are minimal. Regards, Zoltan > Thanks for the suggestions, Kenneth. > > I'm refining the code and trying to enable the last major component - the > low level interpreter for x32. > Yes it's ideal if we can upstream the code, and as you mentioned, keep > maintaining it. The buildbot is a good idea while we are still way far > from it - it requires a mature x32 system which at least supports all of > the things that a WebKit port depends on. I know there're efforts porting > Gentoo and Fedora to x32 - we may depend on each other. > > Currently I'm testing the JSC shell only. Though I use the EFL port, I > eliminated most of the unnecessary dependencies on EFL libraries to run > the JSC shell, so that I don't need to put efforts on compiling and > enabling those dependencies for x32 at current stage. > > Thanks, -Yuqiang > > -Original Message- > From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] > Sent: 2012年10月11日 5:51 > To: Xian, Yuqiang > Cc: webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] x32 support of JavaScriptCore > > Hi, > > I don't think another branch on webkit.org will help you much; then > you can as well have a branch anywhere. > > If you want this code to be well tested and maintained, you need to > get it upstream (through all the review process) and promise that you > have resources to keep maintaining it. It will also be an advantage if > we can get a buildbot running this exact configuration, so that others > can make sure they don't break your code. > > I think that whether the community will accept it upstream depends > much about your commitment and the quality of the code, as well as how > well you interact with the community during the reviews. > > Which port of WebKit is you currently using for testing? > > Cheers > Kenneth > > > On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang > wrote: >> Hi, >> >> >> >> As you may already know there’s a new x32 ABI – a 32-bit psABI for >> x86-64 >> with 32-bit pointer size. It tries to leverage the advantage of more >> registers and IP relative addressing from x64 and the advantage of >> smaller >> memory footprint from IA32. You can find more details of the x32 ABI >> here: >> https://sites.google.com/site/x32abi/. >> >> >> >> The Linux kernel supports x32 since 3.4, and the commonly used >> development >> tools and libraries are getting in the x32 support. Also more details >> about >> current status is available in the above link. >> >> >> >> Now back to WebKit. In theory most part of the WebKit code should be >> fine >> (or require less efforts) to support x32, if they’re pure C++ code and >> can >> be compiled with the x32 toolchain. The major challenge is the JIT >> compiler >> in the JavaScript engine (and the low level interpreter) and some >> hand-written assembly code. So I’m currently working on enabling the >> x32 >> support of JavaScriptCore, the WebKit JavaScript engine, to try to >> remove >> the major obstacle. My current status is that I
Re: [webkit-dev] x32 support of JavaScriptCore
OK, I see. If most of your changes are in JavaScriptCore, it might be possible to just have a build bot that builds that and runs the unit tests for now, then later get all of WebKit tested. Kenneth On Thu, Oct 11, 2012 at 9:13 AM, Xian, Yuqiang wrote: > Thanks for the suggestions, Kenneth. > > I'm refining the code and trying to enable the last major component - the low > level interpreter for x32. > Yes it's ideal if we can upstream the code, and as you mentioned, keep > maintaining it. The buildbot is a good idea while we are still way far from > it - it requires a mature x32 system which at least supports all of the > things that a WebKit port depends on. I know there're efforts porting Gentoo > and Fedora to x32 - we may depend on each other. > > Currently I'm testing the JSC shell only. Though I use the EFL port, I > eliminated most of the unnecessary dependencies on EFL libraries to run the > JSC shell, so that I don't need to put efforts on compiling and enabling > those dependencies for x32 at current stage. > > Thanks, -Yuqiang > > -Original Message- > From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] > Sent: 2012年10月11日 5:51 > To: Xian, Yuqiang > Cc: webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] x32 support of JavaScriptCore > > Hi, > > I don't think another branch on webkit.org will help you much; then > you can as well have a branch anywhere. > > If you want this code to be well tested and maintained, you need to > get it upstream (through all the review process) and promise that you > have resources to keep maintaining it. It will also be an advantage if > we can get a buildbot running this exact configuration, so that others > can make sure they don't break your code. > > I think that whether the community will accept it upstream depends > much about your commitment and the quality of the code, as well as how > well you interact with the community during the reviews. > > Which port of WebKit is you currently using for testing? > > Cheers > Kenneth > > > On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang wrote: >> Hi, >> >> >> >> As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64 >> with 32-bit pointer size. It tries to leverage the advantage of more >> registers and IP relative addressing from x64 and the advantage of smaller >> memory footprint from IA32. You can find more details of the x32 ABI here: >> https://sites.google.com/site/x32abi/. >> >> >> >> The Linux kernel supports x32 since 3.4, and the commonly used development >> tools and libraries are getting in the x32 support. Also more details about >> current status is available in the above link. >> >> >> >> Now back to WebKit. In theory most part of the WebKit code should be fine >> (or require less efforts) to support x32, if they’re pure C++ code and can >> be compiled with the x32 toolchain. The major challenge is the JIT compiler >> in the JavaScript engine (and the low level interpreter) and some >> hand-written assembly code. So I’m currently working on enabling the x32 >> support of JavaScriptCore, the WebKit JavaScript engine, to try to remove >> the major obstacle. My current status is that I have enabled the baseline >> JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore >> tests and the 3 major benchmarks. >> >> >> >> I’m posting this message in order to seek for some advices on how we should >> have our work shared to more people. I understand that it’s not very >> appropriate to try to get it into current WebKit trunk considering current >> x32 support status in major systems and the lack of maintenance in upstream, >> but we want to keep it synchronized with the newest changes of the WebKit >> code. So is it possible for us to maintain the code in a separate branch >> hosted at the WebKit server? >> >> >> >> Any suggestions are appreciated. >> >> >> >> Thanks, -Yuqiang >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev >> > > > > -- > Kenneth Rohde Christiansen > Senior Engineer, WebKit, Qt, EFL > Phone +45 4093 0598 / E-mail kenneth at webkit.org > > ﹆﹆﹆ -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4093 0598 / E-mail kenneth at webkit.org ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On 10/10/2012 10:26 AM, Mark Toller wrote: What we would like to see initially is Webkit based browsers (Chrome, Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the user to download the content - this would indirectly benefit the end goal of Webkit (to get everyone to support standard W3C/HTML5)... This particular change is just a matter of adding one more displayable mime-type, right? Dominik -- Dominik Röttsches ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
> -Original Message- > From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com] > > On 10/10/2012 10:26 AM, Mark Toller wrote: > > What we would like to see initially is Webkit based browsers (Chrome, > > Safari, Minibrowser, etc) actually load HbbTV pages instead of asking > > the user to download the content - this would indirectly benefit the > > end goal of Webkit (to get everyone to support standard W3C/HTML5)... > > This particular change is just a matter of adding one more displayable > mime-type, right? Almost. I've created a bug and patch for this particular change: https://bugs.webkit.org/show_bug.cgi?id=99049 As someone else stated, I think the best approach is to create a bug for each change we consider worthwhile, and then they can be considered individually. Regards, Mark. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Transformations precision: double -> float
On Oct 10, 2012, at 9:00 AM, Gabor Rapcsanyi wrote: > That was a long time ago and there were no objections >> Unless there's something in the spec requiring double precision it makes >> sense to move away from double precision throughout WebKit. I’m a little concerned about this. The programming interface to the graphics system on OS X uses doubles, so it’s likely we’ll be introducing float to double conversions for at least that platform if we change things inside WebKit that are currently doubles to float en masse. Similarly, the native data type for numbers in JavaScript is double. So any time we are passing a number from JavaScript to WebKit it’s likely that additional double to float conversions will be required as we change internals to use doubles instead of floats. On the other hand, there may also be performance boost or memory gains from using float instead of double. If we do make this change, I think we need to do performance testing as we do so, perhaps on more than one platform, to see if these changes are leading to benefits or not. I also think that “we should always use float unless a spec mandates double” is probably not the right rule of thumb. There are many factors other than “a spec” at play here. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On Oct 11, 2012, at 7:40 AM, Mark Toller wrote: >> -Original Message- >> From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com] >> >> On 10/10/2012 10:26 AM, Mark Toller wrote: >>> What we would like to see initially is Webkit based browsers (Chrome, >>> Safari, Minibrowser, etc) actually load HbbTV pages instead of asking >>> the user to download the content - this would indirectly benefit the >>> end goal of Webkit (to get everyone to support standard W3C/HTML5)... >> >> This particular change is just a matter of adding one more displayable >> mime-type, right? > > Almost. I've created a bug and patch for this particular change: > > https://bugs.webkit.org/show_bug.cgi?id=99049 > > As someone else stated, I think the best approach is to create > a bug for each change we consider worthwhile, and then they can be > considered individually. I don't think we should take this change or accept this feature in general. It seems that of those who have spoken up, the WebKit community is not in favor of this direction. Even though the specific change in that patch is relatively small, supporting custom MIME types has significant disadvantages: - Creates interoperability issues with other browsers. - Fragments the web - Opens us up to further requests to add support for similarly niche MIME types in the future If CE-HTML and HbbTV content is fine to process as ordinary HTML, then it should be served with text/html MIME type. That would avoid all of these problems. If a consortium decided to create custom mime types instead, then they made a mistake and should fix it. In some cases, when the technology is compelling or there is a wealth of existing content, we live with arguable errors in the standard. But neither of those considerations applies here. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] x32 support of JavaScriptCore
Hi Yuqiang, I think that this could be a good refactoring for the MacroAssembler – to move all ( Ptr->32 / Ptr->64 ) remapping into MacroAssembler.h, introduce a Imm64, rename all the current *Ptr* methods in MacroAssemblerX86_64 to *64*, etc – please feel free to put up patches for this, and cc me. If this is the bulk of your changes, it may not be a problem to upstream support if you'll be prepared to maintain, and if that doesn't work out it should at least reduce the size of your diff. We prefer incremental changes, so please split out any refactoring that will affect all platforms from changes to support x32, these should be landed separately. cheers, G. On Oct 11, 2012, at 1:52 AM, Xian, Yuqiang wrote: > On X32, the size of a pointer or a "long" integer is 4 bytes instead of 8 > bytes on X64, while the register size is still 8 bytes. > > In JavaScriptCore implementation for X64, it assumes that the JSValue size is > same to the pointer size, and thus EncodedJSValue is simply type defined as a > "void*". In the JIT compiler, we also take this assumption and invoke the > same macro assembler interface for both JSValue and pointer operands. So the > primary task for x32 support is to differentiate the operations on pointers > from the operations on JSValues, and let them invoking different macro > assembler interfaces. For example, we now use the interface of "loadPtr" to > load either a pointer or a JSValue, and we need to switch to using "loadPtr" > to load a pointer and some new "load64" interface to load a JSValue. > The major modification I made is to introduce the "*64" interfaces in the > MacroAssembler, make the "*Ptr" interfaces platform dependent implemented > (one for X32 and the other for X64), and go through all the JIT compiler code > to identify which interfaces should be used. > Also, the calling convention needs to be cared. For example on X64 you may > need two registers to pass or return a structure with two pointer size > members, while on X32 those two members are placed in one register. > > Thanks, -Yuqiang > > -Original Message- > From: Zoltan Herczeg [mailto:zherc...@webkit.org] > Sent: 2012年10月11日 15:43 > To: Xian, Yuqiang > Cc: Kenneth Rohde Christiansen; webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] x32 support of JavaScriptCore > > Just out of curiosity, how much code modifications are required? I read > the ABI documentation the link you attached, and "x32" is a regular 64 bit > mode, except it seems to me that the global descriptor table is tweaked to > store the same descriptors for all 4G address spaces, so the upper 32 bit > is basically ignored when you access a memory address. It is called Small > Code Model or something. I suspect the changes in the JIT code are > minimal. > > Regards, > Zoltan > >> Thanks for the suggestions, Kenneth. >> >> I'm refining the code and trying to enable the last major component - the >> low level interpreter for x32. >> Yes it's ideal if we can upstream the code, and as you mentioned, keep >> maintaining it. The buildbot is a good idea while we are still way far >> from it - it requires a mature x32 system which at least supports all of >> the things that a WebKit port depends on. I know there're efforts porting >> Gentoo and Fedora to x32 - we may depend on each other. >> >> Currently I'm testing the JSC shell only. Though I use the EFL port, I >> eliminated most of the unnecessary dependencies on EFL libraries to run >> the JSC shell, so that I don't need to put efforts on compiling and >> enabling those dependencies for x32 at current stage. >> >> Thanks, -Yuqiang >> >> -Original Message- >> From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] >> Sent: 2012年10月11日 5:51 >> To: Xian, Yuqiang >> Cc: webkit-dev@lists.webkit.org >> Subject: Re: [webkit-dev] x32 support of JavaScriptCore >> >> Hi, >> >> I don't think another branch on webkit.org will help you much; then >> you can as well have a branch anywhere. >> >> If you want this code to be well tested and maintained, you need to >> get it upstream (through all the review process) and promise that you >> have resources to keep maintaining it. It will also be an advantage if >> we can get a buildbot running this exact configuration, so that others >> can make sure they don't break your code. >> >> I think that whether the community will accept it upstream depends >> much about your commitment and the quality of the code, as well as how >> well you interact with the community during the reviews. >> >> Which port of WebKit is you currently using for testing? >> >> Cheers >> Kenneth >> >> >> On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang >> wrote: >>> Hi, >>> >>> >>> >>> As you may already know there’s a new x32 ABI – a 32-bit psABI for >>> x86-64 >>> with 32-bit pointer size. It tries to leverage the advantage of more >>> registers and IP relative addressing from x64 and the advantage of >>>
[webkit-dev] Interface design question
Hello,
Have a design related question and hope to hear some insights.
Interfaces using abstract classes impose restriction(s) on it's derived
implementations.
- The most widely used restriction is to IMPLEMENT Function(s)
Question:
Is it permissible to have similar kind of restriction for any data
members in the interface?
In a way that if some one wants to implement the interface it also must
initialize certain variable.
Ex:
Say for a TCP/IP it absolutely necessary to have
peer's IP address and Port number.
So, is wise to impose a restriction to pass above variable to
initialize the class.
class IP4Connection
{
public:
explicit IP4Connection( string ip, uint port);
virtual int send() = 0;
virtual int listen() = 0;
virtual int reconnect() = 0;
protected:
std::string ip;
uint port;
};
Thanks,
Siva.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Interface design question
webkit-dev doesn't seem like an appropriate place to discuss this topic
unless you have a specific WebKit patch or bug that relates this design
question.
On Thu, Oct 11, 2012 at 1:19 PM, Siva B wrote:
> Hello,
>
> Have a design related question and hope to hear some insights.
>
> Interfaces using abstract classes impose restriction(s) on it's
> derived implementations.
> - The most widely used restriction is to IMPLEMENT Function(s)
>
> Question:
> Is it permissible to have similar kind of restriction for any
> data members in the interface?
> In a way that if some one wants to implement the interface it also
> must initialize certain variable.
>
> Ex:
>
> Say for a TCP/IP it absolutely necessary to have peer's IP address
> and Port number.
> So, is wise to impose a restriction to pass above variable to
> initialize the class.
>
> class IP4Connection
> {
>public:
> explicit IP4Connection( string ip, uint port);
> virtual int send() = 0;
> virtual int listen() = 0;
> virtual int reconnect() = 0;
>protected:
> std::string ip;
> uint port;
> };
>
> Thanks,
> Siva.
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Interface design question
I'am Sorry.
Siva.
From: Ryosuke Niwa
To: Siva B
Cc: "webkit-dev@lists.webkit.org"
Sent: Thursday, October 11, 2012 2:43 PM
Subject: Re: [webkit-dev] Interface design question
webkit-dev doesn't seem like an appropriate place to discuss this topic unless
you have a specific WebKit patch or bug that relates this design question.
On Thu, Oct 11, 2012 at 1:19 PM, Siva B wrote:
Hello,
>
> Have a design related question and hope to hear some insights.
>
> Interfaces using abstract classes impose restriction(s) on it's derived
>implementations.
> - The most widely used restriction is to IMPLEMENT Function(s)
>
> Question:
> Is it permissible to have similar kind of restriction for any data
>members in the interface?
> In a way that if some one wants to implement the interface it also
>must initialize certain variable.
>
> Ex:
>
> Say for a TCP/IP it absolutely necessary to have
peer's IP address and Port number.
> So, is wise to impose a restriction to pass above variable to
>initialize the class.
>
> class IP4Connection
> {
> public:
> explicit IP4Connection( string ip, uint port);
> virtual int send() = 0;
> virtual int listen() = 0;
> virtual int reconnect() = 0;
>
protected:
> std::string ip;
> uint port;
> };
>
>Thanks,
>Siva.
>___
>webkit-dev mailing list
>webkit-dev@lists.webkit.org
>http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unprefixing requestAnimationFrame
I've posted a patch to remove the "webkit" prefix from requestAnimationFrame. [1] The question is whether or not to continue to support the prefixed version. I propose dropping it for the following reasons: 1. We're changing the callback semantics to match the spec. [2] 2. IE10 is shipping with this unprefixed. [3] 3. Toolkits already use the unprefixed version. [4] 4. The advice on the internet recommends everyone use the polyfill technique. [5] I'm curious what everyone else thinks. James [1] https://bugs.webkit.org/show_bug.cgi?id=99116 [2] https://bugs.webkit.org/show_bug.cgi?id=66683 [3] http://caniuse.com/#feat=requestanimationframe [4] https://gist.github.com/1579671 [5] https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixing requestAnimationFrame
>From early on, requestAnimationFrame articles and documentation recommended shims/polyfills alongside the prose. Because of this nearly every script & library using rAF detects all prefixes and the unprefixed standard version. More than nearly any other prefixed API I can think of, shipping unprefixed rAF without the prefixed alias should be safe. On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen wrote: > I've posted a patch to remove the "webkit" prefix from > requestAnimationFrame. [1] The question is whether or not to continue to > support the prefixed version. I propose dropping it for the following > reasons: > > 1. We're changing the callback semantics to match the spec. [2] > > 2. IE10 is shipping with this unprefixed. [3] > > 3. Toolkits already use the unprefixed version. [4] > > 4. The advice on the internet recommends everyone use the polyfill > technique. [5] > > I'm curious what everyone else thinks. > > James > > [1] https://bugs.webkit.org/show_bug.cgi?id=99116 > [2] https://bugs.webkit.org/show_bug.cgi?id=66683 > [3] http://caniuse.com/#feat=requestanimationframe > [4] https://gist.github.com/1579671 > [5] > https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixing requestAnimationFrame
I agree with what Adam wrote in https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites will magically failover to the unprefixed API, we can't know for sure that this change won't break sites. We need to give them a chance to update. (I don't know if one Chrome release cycle will be enough.) Why not be conservative here? -Darin On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen wrote: > I've posted a patch to remove the "webkit" prefix from > requestAnimationFrame. [1] The question is whether or not to continue to > support the prefixed version. I propose dropping it for the following > reasons: > > 1. We're changing the callback semantics to match the spec. [2] > > 2. IE10 is shipping with this unprefixed. [3] > > 3. Toolkits already use the unprefixed version. [4] > > 4. The advice on the internet recommends everyone use the polyfill > technique. [5] > > I'm curious what everyone else thinks. > > James > > [1] https://bugs.webkit.org/show_bug.cgi?id=99116 > [2] https://bugs.webkit.org/show_bug.cgi?id=66683 > [3] http://caniuse.com/#feat=requestanimationframe > [4] https://gist.github.com/1579671 > [5] > https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
