No. Just no.

[jbash]

This is a mind-shatteringly bad idea. Don't do it. There's a risk that
it might actually get adopted, which would be horrible.

First of all, given that the instruction set can change and processors
have obscure bugs, there's no way you're going to make me believe a
sandbox is actually working right and will continue to work right
throughout the future on all platforms.

Second, it's a bad idea EVEN IF IT WORKS. The X86 architecture has a
finite useful life. Do NOT tie the Web to the X86 architecture. If
this catches on, people will find themselves writing X86 emulators to
run this stuff in 10 years or less. The performance penalty of using
those emulators over running the native code of that time will be at
least as great as the performance penalty of, say, a Java engine now.

If you really want to solve this problem, come up with a way of
representing code that can be efficiently JIT-compiled AND OPTIMIZED.
That probably means directly representing the programmer's
abstractions, not requiring the JIT to infer them from could-mean-
anything code.

X86 code is not an appropriate general-purpose machine-readable
program representation. Stop trying to abuse it as such.

[Lerc]

> X86 code is not an appropriate general-purpose machine-readable
> program representation. Stop trying to abuse it as such.

Actually an appropriate subset of x86 is a reasonable representation.

Once you are using flat 32 bit user level code a subset of x86
instructions is perfectly capable. Instructions such as XLAT or the
various BCD options are not required and, in general slower.

The functional base is quite generic, with the main distinction from
other processors is fewer registers and it doesn't use a load-store
architecture.

If you want something today, you want it to perform well on x86, and
executing code that is a close fit works. In the future a translation
to other instructions sets is quite feasible. It is much easier to
emulate a machine with few registers on one with many than the other
way around.

[Peter da Silva]

I'm with you. Microsoft has been trying to push native applets for
over a decade now, it was a daft idea in 1997, it's a daft idea in
2008.

The x86 instruction set is too irregular, too prone to change, and has
too many side effects for this purpose. Stick to a high level ISA and
leave things like native code recompilation at the implementation
level.

[moodz]

On Dec 10, 3:05 am, jbash <jb...@velvet.com> wrote:
> This is a mind-shatteringly bad idea. Don't do it. There's a risk that
> it might actually get adopted, which would be horrible.

could say exactly the same about a certain language orginally designed
to run toasters ...

> First of all, given that the instruction set can change and processors
> have obscure bugs, there's no way you're going to make me believe a
> sandbox is actually working right and will continue to work right
> throughout the future on all platforms.

the byte codes can change and the VM has obscure bugs and theres no
way etc etc.

>
> Second, it's a bad idea EVEN IF IT WORKS. The X86 architecture has a
> finite useful life. Do NOT tie the Web to the X86 architecture. If
> this catches on, people will find themselves writing X86 emulators to
> run this stuff in 10 years or less. The performance penalty of using
> those emulators over running the native code of that time will be at
> least as great as the performance penalty of, say, a Java engine now.

It is already tied to the X86 architecture ( OK some argument here )
and future multicore
X86 multithread is going to pump monolithic JVM threading.

>
> If you really want to solve this problem, come up with a way of
> representing code that can be efficiently JIT-compiled AND OPTIMIZED.
> That probably means directly representing the programmer's
> abstractions, not requiring the JIT to infer them from could-mean-
> anything code.

I am glad you mention opimization since Java really needs this.
Optimized C will pump your Java apps. Pointers anyone ?
Having mucked extensively with reloadable classes in Java I can
attest to the lack lustre performance in this respect.

>
> X86 code is not an appropriate general-purpose machine-readable
> program representation. Stop trying to abuse it as such.

this is an oxymoron ... X86 has been machine readable for aeons.

[nme]

I disagree about opinion above that X86 architecture is a bad choice.
It is native architecture of the workstations we all use. As I read,
NaCl will be available for ARM processors too. An application for ARM
should be compiled to its architecture as a bytecode, where it will be
able to run on native processor. Compiler stays the same, API will
still be the same. Those are the things which make Native Client way
to develop applications completly architecture independent. Code
migration between CPU architecture with whole Posix environment around
will be WAY simpler than moving it between different OS'es.

We all suffer from X86 dominance which should be replaced few years
ago. But it isn't. Apple replaced PPC with X86. Sun needs to sell X86
arch machines. X86 is cheap, massive and available everywhere... Just
like ARM will be in a few years... Nothing seems to change the fact
that X86 will stay at the top for next 10 years of highest computing
speed cheap & wide available.

The question I'm asking is what is the Google master plan behind
NaCl... My bet - in a year since now a Google user will have a choice
1) see google ads 2) give a google 1% of his CPU for their currently
Top Secret AI project :)

[Chris 'Xenon' Hanson]

On Dec 9, 9:05 am, jbash <jb...@velvet.com> wrote:
> Do NOT tie the Web to the X86 architecture.

Point of order -- browser plugins are already 100% tied to the
architecture they are compiled for, and even more limitingly, the
browser API and OS platform they were built for too.

NaCl (great name!) is trying to pry the current situation away from
the restrictive browser API (Mozilla vs Safari vs IE0 and Platform
(Windows vs Linux vs MacOSX) by providing a thin but secure
abstraction/services layer that works identically and equally well on
all of them.

You're focusing on x86, but nothing about NaCl is specific to x86. GCC
is a GREAT cross-compiler, and I expect Google will provide ARM and
other targets pretty soon. They're tight with both Android phones and
the iPhone, so you can expect they'll want to stay on the good side
there. So they will be separating the execution environment from the
x86 architecture too, over time, providing a fully abstracted web
application environment.

It can only be a good thing that you will be able to write installable
browser plugins AND ephemeral web applications in the same environment
and toolchain.

Microsoft is probably very worried about this countershot to
Silverlight's attempt at web development dominance and vendor/
toolchain lock-in. NaCl, is the spectre of the Netscape "The web is
the OS/platform" missive of the 90s that Microsoft was so terrified of
they stopped at nothing to destroy Netscape. Only, the Netscape DNA
lived on, zombie-like in the Mozilla project, matured, mutated and (in
spirit anyway) brought about Chrome, and now NaCl. only this time the
zombie is backed by the might of Google, and unlike Netscape, they
know exactly how much of a threat they are to Microsoft and have the
resources to put up a serious fight.

VERY interesting. If this flies, you're watching the opening shots of
what could be a VERY long and nasty battle for the openess of the
platform that powers the front-end of the web of the future. Apache on
the back-end and Chrome+NaCl on the front end will be a two-front war
that could tear Microsoft's long-locked platform to shreds. I'm
wondering if NaCl is a clever jab at "salt in their wounds"? ;)

[Tom 94301]

> Second, it's a bad idea EVEN IF IT WORKS. The X86 architecture has a
> finite useful life.

What's the alternative? Look at the JVM. x86, even x86/32 has been
around longer than the JVM. And for all its flaws, x86 is a better
instruction set than the JVM instruction set. x86 has also been more
stable than .NET and Flash, and a whole bunch of technologies we don't
even remember. And x86 can be supported reasonably on non-x86
architectures via JIT. Furthermore, who cares whether this design
lasts? Since, unlike Java or C#, there is no big commitment and I can
just compile the code I already have.