[Vm-dev] Squeak VM port to Google Native Client

Yoshiki Ohshima yoshiki at vpri.org
Wed Aug 31 17:52:28 UTC 2011


At Wed, 31 Aug 2011 10:41:49 -0300,
Javier Pimás wrote:
> 
> hi! We've already made it compile with PP 0.5, but it's not displaying anything in the browser. Maybe it's the image or the browser version, or something related to PPAPI
> changes. Which image and chrome version did you use? Actually, we tried your live demo but it isn't working in our browser either.

  I started with NaCl SDK 0.2.  That was for Chrome 11 or 12?  The
vanilla 4.1 Squeak image did work and so did 3.0, IIRC.

  One part that we would need to look at is how the JavaScript code in
squeak.html drives display cycle. This part seems to be changed a lot
(Many parts have changed on their side).


  What I'd do is to revive my test project
(git://github.com/yoshikiohshima/NaClueakTest.git) first.  As you can
see this is basically a hybrid of hello_world and pi_generator with
the interpret() function that runs in infinite loop.  I'd start again
from the latest hello_world.c that works.  Then, convert some C++ code
in pi_generator to C and merge it into hello_world in the way similar
to the stuff in my code.

  I did NaClueakTest experiment on Windows, but I strongly urge to
play with Native Client on Linux.  My Log() function can be replaced
with fprintf to stderr and you can do more sensible debugging.

  Hope this helps.  If you have more troubles, I'd like to find some
time to do it by myself.  It should not take too long.

-- Yoshiki

> On Mon, Aug 29, 2011 at 2:15 PM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:
> 
>     At Mon, 29 Aug 2011 11:22:03 -0300,
>     Javier Pimás wrote:
>     >
>     > Hi Yoshiki, we are starting to work on this, and maybe you can help us. I wanted to know what setup did you use for the tools, and what workflow you follow. Some
>     > questions I can think of now:
>     >
>     > - do you download your git repo over the squeak-svn?
>     > - do you generate the code for unix and then modify by hand or you generate for a new platform?
>     > - Is there any image code?
>    
>      Hi Javier!
>    
>      Last time I touched it was early May, and so much has changed in the
>     Native Client SDK since then.  It was SDK 0.2 and now it is 0.5.  Good
>     news is that they claim that API is now stabilizing (which should be
>     somewhat different from 0.2), so now we can have a bit more stable
>     version of VM, presumably.
>    
>      - My git repo was basically "on its own"; Into an empty git
>        repository, I copied files (one file by one file) from squeak-svn
>        and edit them as needed.  (So, that was the discussion you quoted;
>        I still think many files can be reused with a bit more ifdefs in
>        the Unix code.)
>    
>      - The annoying kind of generated files, such as config.h, were
>        indeed hand edited.
>    
>      - There is no code for image side yet.  A bridge to Pepper API is
>        called for, however.
>    
>     > also, I'm seeing that you use a common.mk file for extra configuration for the makefile. Could you please pass it to me so that I get an example of what's missing?
>    
>      Around this part of the SDK is radically changed since then.
>     Common.mk in the examples/ directory looked like the following back
>     then.  But it needs to be adopted the new regime.
>    
>     -- Yoshiki
>    
>     -----------------------------------
>     # Copyright (c) 2011, The Native Client Authors. All rights reserved.
>     # Use of this source code is governed by a BSD-style license that can be
>     # found in the LICENSE file.
>     #
>     # Common makefile for the examples.  This has some basic variables, such as
>     # CC (the compiler) and some suffix rules such as .c.o.
>     #
>     # The main purpose of this makefile component is to demonstrate building a
>     # Native Client module (.nexe)
>    
>     .SUFFIXES: .c .cc .cpp .o
>    
>     .PHONY: check_variables
>    
>     ifeq ($(origin OS), undefined)
>      ifeq ($(shell uname -s), Darwin)
>        OS=Darwin
>      else
>        OS=$(shell uname -o)
>      endif
>     endif
>    
>     ifeq ($(OS), $(filter $(OS), Windows_NT Cygwin))
>      PLATFORM = win
>      TARGET = x86
>     endif
>     ifeq ($(OS), $(filter $(OS), Darwin MACOS))
>      PLATFORM = mac
>      TARGET = x86
>     endif
>    
>     # Look for 'Linux' in the $(OS) string.  $(OS) is assumed to be a Linux
>     # variant if the result of $(findstring) is not empty.
>     ifneq (, $(findstring Linux, $(OS)))
>      PLATFORM = linux
>      TARGET = x86
>     endif
>    
>     PYTHON ?= /usr/bin/python
>     NACL_SDK_ROOT ?= .
>    
>     NACL_TOOLCHAIN_DIR = toolchain/$(PLATFORM)_$(TARGET)
>    
>     CC = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-gcc
>     CPP = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-g++
>     NACL_STRIP = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-strip
>     NACL_SEL_LDR32 = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-sel_ldr
>     NACL_SEL_LDR64 = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl64-sel_ldr
>    
>     CFLAGS = -Wall -Wno-long-long -pthread -Werror
>     OPT_FLAGS = -O2
>     DEBUG_FLAGS = -g
>    
>     # Make all the object files depend on the entire list of header files.  This
>     # is a little brutal, but it gets the job dome simply without a make depend
>     # step.
>     %_x86_32_dbg.o: %.c $(HFILES)
>            $(CC) $(CFLAGS) -m32 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $<
>    
>     %_x86_32_dbg.o: %.cc $(HFILES)
>            $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $<
>    
>     %_x86_64_dbg.o: %.c $(HFILES)
>            $(CC) $(CFLAGS) -m64 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $<
>    
>     %_x86_64_dbg.o: %.cc $(HFILES)
>            $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $<
>    
>     %_x86_32.o: %.c $(HFILES)
>            $(CC) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>    
>     %_x86_32.o: %.cc $(HFILES)
>            $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>    
>     %_x86_32.o: %.cpp $(HFILES)
>            $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>    
>     %_x86_64.o: %.c $(HFILES)
>            $(CC) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>    
>     %_x86_64.o: %.cc $(HFILES)
>            $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>    
>     %_x86_64.o: %.cpp $(HFILES)
>            $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>    
>     # Generate list of .o files based on the list of .c and .cc files
>     OBJECTS_X86_32 = $(CFILES:%.c=%_x86_32.o) $(CCFILES:%.cc=%_x86_32.o)
>     OBJECTS_X86_64 = $(CFILES:%.c=%_x86_64.o) $(CCFILES:%.cc=%_x86_64.o)
>     OBJECTS_X86_32_DBG = $(CFILES:%.c=%_x86_32_dbg.o) $(CCFILES:%.cc=%_x86_32_dbg.o)
>     OBJECTS_X86_64_DBG = $(CFILES:%.c=%_x86_64_dbg.o) $(CCFILES:%.cc=%_x86_64_dbg.o)
>    
>     # Make sure certain variables are defined.  This rule is set as a dependency
>     # for all the .nexe builds in the examples.
>     check_variables:
>     ifeq ($(origin OS), undefined)
>            @echo "Error: OS is undefined" ; exit 42
>     endif
>     ifeq ($(origin PLATFORM), undefined)
>            @echo "Error: PLATFORM is undefined (OS = $(OS))" ; exit 42
>     endif
>     ifeq ($(origin TARGET), undefined)
>            @echo "Error: TARGET is undefined (OS = $(OS))" ; exit 42
>     endif
>     ifeq ($(origin NACL_SDK_ROOT), undefined)
>            @echo "Error: NACL_SDK_ROOT is undefined" ; exit 42
>     endif
> 
> --
> Lic. Javier Pimás
> Ciudad de Buenos Aires
> 
> 


More information about the Vm-dev mailing list