"[...] The earlier 'SIMD' instruction sets on the x86 platform, from oldest to
newest, are 'MMX', '3DNow!' (developed by AMD), 'SSE' and 'SSE2'. [...]"
Source: https://en.wikipedia.org/wiki/SSE3 (At the top.)
Is support for 'MMX' & '3DNow!' already dropped?
-BesTo
___
The baseline compiler has modest needs and should be able to target a
simple wasm interpreter fairly easily.
--lars
On Sun, May 22, 2016 at 11:08 PM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser
> wrote:
>
> > On 5/18/16 10:41 PM, Jan
On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser
wrote:
> On 5/18/16 10:41 PM, Jan de Mooij wrote:
>
>> They do get the baseline compiler, which can still be significantly
>>> faster than the interpreter, but Ion requires SSE2. Since the runtime
>>> detection does just turn Ion off altogether, I
On 5/18/16 10:41 PM, Jan de Mooij wrote:
They do get the baseline compiler, which can still be significantly faster than
the interpreter, but Ion requires SSE2. Since the runtime detection does just
turn Ion off altogether, I don't know if we would gain much by removing it (the
ability to disa
On Thu, May 19, 2016 at 12:31 PM, Mike Hommey wrote:
> I don't think anyone suggested to add support for runtime selection of
> SSE2 for code that is not inline asm.
The code that I'm most immediately interested in replacing with Rust
with SSE2 intrinsics without runtime selection currently uses
On Thu, May 19, 2016 at 12:30 PM, Kurt Roeckx wrote:
> On 2016-05-18 10:10, Henri Sivonen wrote:
>>
>> What do we need to do to reach a decision that it's indeed OK to treat
>> *run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
>> "patches not even welcome" kind of thing, consi
On 2016-05-18 10:10, Henri Sivonen wrote:
What do we need to do to reach a decision that it's indeed OK to treat
*run-time* selection of SSE2 vs. non-SSE2 especially in Rust code as a
"patches not even welcome" kind of thing, considering that this may
lead to Linux distros shipping an 32-bit x86
On Thu, May 19, 2016 at 12:07:42PM +0300, Henri Sivonen wrote:
> On Wed, May 18, 2016 at 8:32 PM, Benjamin Smedberg
> wrote:
> > Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am
> > comfortable making that decision today.
>
> Thank you! I filed
> https://bugzilla.mozilla.org
On Wed, May 18, 2016 at 8:32 PM, Benjamin Smedberg
wrote:
> Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am
> comfortable making that decision today.
Thank you! I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1274196 for this.
> Should we also take actions that preven
On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen <
emanuel.hoogev...@gmail.com> wrote:
> They do get the baseline compiler, which can still be significantly faster
> than the interpreter, but Ion requires SSE2. Since the runtime detection
> does just turn Ion off altogether, I don't know if we w
On Thu, May 19, 2016 at 2:59 AM, Emanuel Hoogeveen
wrote:
>
> They do get the baseline compiler, which can still be significantly faster
> than the interpreter, but Ion requires SSE2. Since the runtime detection does
> just turn Ion off altogether, I don't know if we would gain much by removing
On Wednesday, May 18, 2016 at 7:32:38 PM UTC+2, Benjamin Smedberg wrote:
> - Our own JITs and their support for non-SSE2 paths
> - Our primary JIT doesn't support non-SSE2, right? So these users
> already fall back to the slow interpretation path?
They do get the baseline compile
Am Mittwoch, 18. Mai 2016 20:28:01 UTC+2 schrieb Tobias B. Besemer:
> > If we're going to accidentally keep introducing bugs where non-SSE2 CPUs
> > crash, it would be far better to add a runtime check at the beginning of
> > main() and error out, than to have a steady trickle of bug reports about
On 2016-05-18 1:32 PM, Benjamin Smedberg wrote:
- Other platform code that does dynamic SSE2 detection. For example,
image decoders which we compiler in both SSE2 and non-SSE2 configs
currently, and select the codepath at runtime.
- I imagine we'd like to remove this complexity fro
On Wed, May 18, 2016 at 9:51 AM, Ralph Giles wrote:
> On Wed, May 18, 2016 at 3:54 AM, Mike Hommey wrote:
>
> > Now, with my Debian hat on, I can tell you with 100% certainty that
> > angry Debian users *will* come with patches and will return even
> > angrier if patches are not even welcome.
>
> If we're going to accidentally keep introducing bugs where non-SSE2 CPUs
> crash, it would be far better to add a runtime check at the beginning of
> main() and error out, than to have a steady trickle of bug reports about
> crashes on illegal instructions which end up being marked INVALID.
Thin
On Wed, May 18, 2016 at 11:10:30AM +0300, Henri Sivonen wrote:
>> So we now require SSE2 on [...]
>> * 32-bit x86 Mac, which means just the plugin-container now that we
>> no longer support 10.6, which was the last OS X version that ran on
>> 32-bit hardware.
Actually, all of Apple's intel hardw
On Wed, May 18, 2016 at 6:54 AM, Mike Hommey wrote:
> Henri Sivonen wrote:
>
> > It seems that we are almost ready to require SSE2 for Mozilla-built
> > Firefox for 32-bit x86 Linux.
>
There are a couple of interrelated issues here.
Can we require SSE2 for Mozilla builds of Firefox for Linux?
I think we need to admit that there isn't any rational, analytical way to
compare most of the costs here. The one number we *do* have, the number of
users who can't upgrade, is kind of tantalizing us, but we can't quantify
how many users we'll gain by requiring SSE2, how many other bugs we'll fix
b
Am Mittwoch, 18. Mai 2016 16:52:25 UTC+2 schrieb Boris Zbarsky:
> On 5/18/16 7:38 AM, Tobias B. Besemer wrote:
> > Is this really a discussion if Firefox should support CPUs older then 13-15
> > years ???
>
> More or less, yes.
>
> > I can't imagine any scenario were a user needs to run a Pentiu
On 5/18/16 7:38 AM, Tobias B. Besemer wrote:
Is this really a discussion if Firefox should support CPUs older then 13-15
years ???
More or less, yes.
I can't imagine any scenario were a user needs to run a Pentium III with GUI
and a browser on it...
There were AMD CPUs newer than that wit
On 2016-05-18 7:38 AM, Tobias B. Besemer wrote:
N00b question:
Is this really a discussion if Firefox should support CPUs older then 13-15
years ??
Right now Firefox supports users on platforms their creators have long
abandoned - WinXP, pre-SSE2 CPUs, OSX 10.6-8, older Android. Firefox is
the
Am Mittwoch, 18. Mai 2016 13:56:14 UTC+2 schrieb Tobias B. Besemer:
> Am Mittwoch, 18. Mai 2016 13:38:58 UTC+2 schrieb Tobias B. Besemer:
> > N00b question:
> > Is this really a discussion if Firefox should support CPUs older then 13-15
> > years ???
> >
> > https://en.wikipedia.org/wiki/SSE2
> >
Am Mittwoch, 18. Mai 2016 13:38:58 UTC+2 schrieb Tobias B. Besemer:
> N00b question:
> Is this really a discussion if Firefox should support CPUs older then 13-15
> years ???
>
> https://en.wikipedia.org/wiki/SSE2
>
> I can't imagine any scenario were a user needs to run a Pentium III with GUI
N00b question:
Is this really a discussion if Firefox should support CPUs older then 13-15
years ???
https://en.wikipedia.org/wiki/SSE2
I can't imagine any scenario were a user needs to run a Pentium III with GUI
and a browser on it...
...would mean that the system not only runs not e.g. as a p
On Wed, May 18, 2016 at 11:10:30AM +0300, Henri Sivonen wrote:
> On Mon, May 16, 2016 at 8:53 PM, Benjamin Smedberg
> wrote:
> > On Mon, May 16, 2016 at 8:47 AM, Henri Sivonen wrote:
> >> For clarification: Does this decision apply to 32-bit x86 Linux as
> >> well? (It would be sad to have to sup
On Mon, May 16, 2016 at 8:53 PM, Benjamin Smedberg
wrote:
> On Mon, May 16, 2016 at 8:47 AM, Henri Sivonen wrote:
>> For clarification: Does this decision apply to 32-bit x86 Linux as
>> well? (It would be sad to have to supply and maintain non-SSE2 x86
>> code paths just for Linux.)
>
> Nobody a
27 matches
Mail list logo
