Google nativeclient

Hi, folks!
What about the subj? http://code.google.com/p/nativeclient/
Can be will port Inferno to that is a good idea?

IMHO, ActiveX sucks ;)

--

-- 
www.andr.ru

Re: Google nativeclient

I thought about it but no network is a pain for inferno.

Sent from my iPhone

On Jan 2, 2009, at 11:53 AM, "Andrew Wingorodov" <mail@...> wrote:

> Hi, folks!
> What about the subj? http://code.google.com/p/nativeclient/
> Can be will port Inferno to that is a good idea?
>
> IMHO, ActiveX sucks ;)
>
> -- 
> www.andr.ru

Re: Google nativeclient

I never got an answer from the newsgroup about whether NaCl supports
JIT'd code.

I've actually been thinking of doing it the other way around and
embedding NaCl in Inferno, or rather, linking libvx32 with inferno.
Then native code would get access to the inferno namespace; the linux
(or plan9) syscalls open, read, write, close, would be redirected to
inferno's syscalls.  Taken to an extreme this is just like running 9vx
and exporting inferno namespace to plan9. But maybe there are other
things that could be done if it was a builtin to inferno. Perhaps
combining dynamic loading of devices with vx32 so that libdynld is OS
independent.

On Fri, Jan 2, 2009 at 12:53 PM, Andrew Wingorodov <mail@...> wrote:
> Hi, folks!
> What about the subj? http://code.google.com/p/nativeclient/
> Can be will port Inferno to that is a good idea?
>
> IMHO, ActiveX sucks ;)
>
> --
> www.andr.ru
>

Re: Google nativeclient

>I never got an answer from the newsgroup about whether NaCl supports
>JIT'd code.

if you're running hosted on a little-endian ARM based on gcc or Plan 9 5c, it
will have the words in doubles and vlongs the wrong way round (because the
part of the 750FPE manual where it tells you which way to put them is easily missed,
and knowing it's there i can rarely find it quickly to prove the point).
it's high-low even on a little-endian processor.  fortunately, there was only
one hardware implementation of that, so it would be easy enough to change Inferno
to match the order used by the others, which will help the JIT and a few
other things.

Re: Google nativeclient

>it will have the words in doubles and vlongs the wrong way round

i meant the host will have them the wrong way round from real hardware.

Re: Google nativeclient

I don't think ARM is on the radar for Google's native client, or vx32.

On Fri, Jan 2, 2009 at 4:48 PM, Charles Forsyth <forsyth@...> wrote:
>>I never got an answer from the newsgroup about whether NaCl supports
>>JIT'd code.
>
> if you're running hosted on a little-endian ARM based on gcc or Plan 9 5c, it
> will have the words in doubles and vlongs the wrong way round (because the
> part of the 750FPE manual where it tells you which way to put them is easily missed,
> and knowing it's there i can rarely find it quickly to prove the point).
> it's high-low even on a little-endian processor.  fortunately, there was only
> one hardware implementation of that, so it would be easy enough to change Inferno
> to match the order used by the others, which will help the JIT and a few
> other things.
>

Re: Google nativeclient

> I've actually been thinking of doing it the other way around ... linking libvx32 with inferno.

I've got some of this working now, very minimal, but I'll post it to
IPN over the weekend.

Re: Google nativeclient

>I don't think ARM is on the radar for Google's native client, or vx32.

i hadn't realised what NaCl stood for. anyway, my note answered one aspect of an earlier
query about JIT on ARM.

Re: Google nativeclient

Re: Google nativeclient