VM-beginners March 2014

vm-beginners@lists.squeakfoundation.org

2 participants
6 discussions

Changes to ObjectMemory needed to get StackInterpreter to compile from generated source
by gettimothy 30 Mar '14

30 Mar '14

Howdy. I have a mcz VMMaker.oscog-tty.661.mcz in my local package-cache if you would like me to push it live. Here is the low-down. Compiling the StackInterpreter from the code currently in SVN in the stacksrc directory works fine--it is probably an artifact from the last time Eliot generated the StackInterpreter source code before moving on to other things. However, using VMMaker,cleaning out that src tree and generating new source results in code that will not compile due to mesage sends to nowhere in NewObjectMemroy>>allInstancesOf: The compile errors look like this: ...oscogvm/stacksrc/vm/gcc3x-interp.c:10108: undefined reference to `minLargeHeaderSize' ...oscogvm/stacksrc/vm/gcc3x-interp.c:10109: undefined reference to `sizeHeaderputBodySize' ...oscogvm/stacksrc/vm/gcc3x-interp.c:10180: undefined reference to `sizeHeaderputBodySize' the unimplemented methods are sizeHeader:putBodySize and minLargeHeaderSize I have not studied the VM architectures yet*, so I just flipped a coin, and took a wild guess at fixing things. For sizeHeader:putBodySize, I did a cut-n-paste from baseHeader:put: sizeHeader: oop putBodySize:aWord ^ self longAt: oop put: aWord. for minLargeHeaderSize, I returned BaseHeaderSize (Hey! BaseHeaderSize just HAS to be a valid header size, soooooo, let's make that the minimum one!). minLargeHeaderSize ^BaseHeaderSize Compilation worked and the image runs. 16 failures and 2 errors in test run. If the above is not correct, I will revisit this after my plugin study and vm architecture study. . * (I will be studying them soon, I feel pretty good about compiling from scratch now and will be moving to Plugins tomorrow--after that, 64 bits or bust baby!--which implies studying the vm architecture in depth )

1 0

StackInterpreter builds....
by gettimothy 29 Mar '14

29 Mar '14

I was able to compile and run the StackInterpreter Image ----- /home/tty/usr/src/smalltalk/runStackVM32/Squeak4.6-13700.image Squeak4.6 latest update: #13700 Current Change Set: Unnamed1 Image format 6505 (32 bit) Virtual Machine --------------- /home/wm/usr/local/stackVM32/lib/squeak/4.0-2886/squeak Croquet Closure Stack VM [StackInterpreter VMMaker.oscog-eem.658] Unix built on Mar 29 2014 14:05:29 Compiler: 4.8.2 platform sources revision VM: r2886 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2014-03-28 19:11:48 -0400 Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins StackInterpreter VMMaker.oscog-eem.658 uuid: e40c5fd5-9990-433f-bd76-2f8d0324e24f Mar 29 2014 but there is much work I need to do and things to learn yet. I had to remove most of the plugins from plugins.int/ext to get the thing to compile and will be adding them back one-by-one to try to get my mind about this. I am thinking that some plugins look in /lib64 instead of /lib for their libraries--that kind of stuff. Once I get fluent at this, we can discuss the port to native 64 or perhaps you would prefer I do some plugin bugs on Cog. Hopefully I can start doing something useful next week. Thanks again for your help tty

1 0

Re: [Vm-dev] This is the StackInterpreter?
by gettimothy 29 Mar '14

29 Mar '14

bah! I have been working in the oscogvm/unixbuild directory and only now noticed the stackbuild/unixbuild tree with its own HowToBuild instructions. My reasoning now is that Cog is the standard , so "src" and "unixbuild" etc belong to it (as it should) while "special stuff" like StackInterpreter etc are shuffled off to their own little world in stacksrc and stackbuild. Thanks for your patience. tty.

1 0

This is the StackInterpreter?
by gettimothy 28 Mar '14

28 Mar '14

What is worse than things not working is when things start working and I don't know why. After a hiatus in PHP land, I am back to Squeak Land and lo and behold, the Stack Interpreter 32 bit compiled and runs the 4.6 image. That is if what you see below is in fact the Stack Interpreter. Please let me know if it is not Image ----- /home/tty/usr/src/smalltalk/runStackVM32/Squeak4.6-13700.image Squeak4.6 latest update: #13700 Current Change Set: Unnamed1 Image format 6505 (32 bit) Virtual Machine --------------- /home/wm/usr/local/stackVM32/lib/squeak/4.0-2881/squeak Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.641] Unix built on Mar 28 2014 12:22:20 Compiler: 4.8.2 platform sources revision VM: r2881 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2014-03-13 20:45:37 -0400 Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins CoInterpreter VMMaker.oscog-eem.641 uuid: c0305b66-db2d-45aa-8d25-267732aa1784 Mar 28 2014 StackToRegisterMappingCogit VMMaker.oscog-eem.641 uuid: c0305b66-db2d-45aa-8d25-267732aa1784 Mar 28 2014 If so, then we have a second data point of building a Stack Interpreter on a 64 bit machine with 32 bit compat libs. file squeak squeak: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped An interesting point of note is of note is that I was getting ready to debug a vm that would not run. It was built with this configure command. ../../../platforms/unix/config/configure CC="gcc -m32" CXX="g++ -m32" --without-npsqueak CFLAGS="-g -O2 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0" LIBS=-lpthread --x-libraries=/usr/lib --prefix=/home/tty/usr/local/stackVM32 and the result was a vm that built, but would hang waiting on what I believed was a signal. Setting out to debug this non-running vm, I changed to -O2 flag to -Og which rhymes with 'd' and that spells "debugging". ../../../platforms/unix/config/configure CC="gcc -m32" CXX="g++ -m32" --without-npsqueak CFLAGS="-g -Og -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0" LIBS=-lpthread --x-libraries=/usr/lib --prefix=/home/tty/usr/local/stackVM32 And, lo and behold, no more trouble in River City. It ran.

1 0

A question concerning the proposed become implementation
by Mateusz Grotek 21 Mar '14

21 Mar '14

Dear VM specialists, I have the following question concerning the proposed (is it already implemented?) become implementation: http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-re… How does this implementation prevent forming long chains of redirections? Let's say I have a variable V1 pointing to an object O1. (V1 -> O1). I have another variable V2 pointing to an object O2. (V2 -> O2). After that I do: V1 becomeForward: V2. Now A points to B, so I have V1 -> O1 -> O2 Now I assign to V2 an object O3: (V2 -> O3) And again do: V1 becomeForward: V2. So I have: V1 -> O1 -> O2 -> O3 I do it a couple of times. Now I have a long chain of redirections: V1 -> O1 -> O2 -> O3 -> O4 -> O5 -> .... -> ON If I save my image it gets saved inside it. So the longer I use my image the longer the chain is. In the end it's longer than my memory and the image crashes. What am I missing? Yours sincerely, Mateusz Grotek

1 1

Standard Interpeter build to 64x64 successful
by gettimothy 13 Mar '14

13 Mar '14

Hi David. I used your instructions at http://wiki.squeak.org/squeak/6177 and your emails reply to successfully build the Standard Interpreter running nativelly on 64 bit linux and powering a 64 bit image from the Jenkins server. I collected 3 series of notes with the quick-n-dirty commands for 3 scenarios and posted them at my blog. If you think its worth linking to from the wiki or incorporating into the wiki, please feel free. HOWTO build a 64 native StandardVM running 32 bit image on Slackware Linux 14.1 with 32 bit compat libs HOWTO Build a 64 native Standard VM running 64 bit image from Jenkins build server HOWTO Build a 64 native Standard VM running 64 bit image built using SystemTracer My attempt at building my own 64 bit image using SystemTracer semi-worked in that it created and image that booted but had no functionality to it. I am not worried about that at the moment. Thank you for your help; its much appreciated. Now that those exercises are over, I am turning my attention to debugging my build of the StackInterpreter using VMMaker.oscog and then to porting that to native 64.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

VM-beginners March 2014