New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Eliot Miranda-2
Hi All,

    first of all, apologies for the long wait for new VMs.  I know there are bugs that these VMs address and that it's been 5 months since VMs were last made is something I regret.  The wait was due to my developing the 64-bit Spur Cog JIT VM which required surgery not just to the Cogit but also to Slang.  I beg your forgiveness.

   Secondly, the Mac VMs are much changed, using John McIntosh's Cocoa support libraries.  The old Carbon UI VMs are history.  That means that Cog supports building on contemporary Mac OS releases.  These VMs were built on 10.9; I like the 3D look much more than the 10.10 one ;-).  The VMs are also signed, so installing them should be easier.

  Thirdly, these VMs include 64-bit JIT support.  There is an updated squeak trunk image at http://www.mirandabanda.org/files/Cog/SpurImages for you to try.  As yet the 64-bit Vms do not include an FFI plugin.  I hope to rectify this soon.

   Finally I have included Pharo Mac VMs, not to displace the official Pharo VMs, but to test my build process.  I hope that in very few months the svn repository will be moed to githup and that Esteban and I will build official VMs from the same repository.




CogVM binaries as per VMMaker.oscog-eem.1679/r3602

Include 64-bit Spur VMs for Mac OS X x64 and Linux x64. N.B. As yet these VMs
lack FFI support.

Move all Mac OS X VMs to the Cocoa libraries.  Minimum supported version should
be 10.6.x.  The Mac OS X VMs are signed and so should install properly without
having to disable the launch security checks.


Bug Fixes and Improvements:

General:
Add vmParameter 20 to answer the utc microseconds at startup.


CoInterpreter:
Remove the atCache from the CoInterpreter.  It's of little benefit given the
Cogit.

ceSend: et al need to add looked up methods to the method cache, otherwise
methods only found through machine code sends will not be jitted.

Fix slip in maybeSelectorOfMethod: which will improve back traces
including methods containing pragmas (including primitives).

Modify secret primtiive 161, primitiveSetIdentityHash so that with 0 args it
answers whether an object has an identity hash.  This is vacuously true for V3,
but is meaningful in Spur.


Cogit:
Fix /horrible/ bug with primitive error codes and fixups.  The adjustment of the
initialPC to skip the primitive and error code, if any, was done after
generating fixups for backward branches, and hence these branches were bogus.
Object>>shallowCopy in Spur is subject to this, but amazingly enough it has not
surfaced before now.  Fix this by adjusting the initialPC before scanMethod
scans for fixups.

Fix bug in Spur machine-code at:put: on 32-bit bits objects; method failed to
fail for negative values.

Fill unused portions of methods with the stop instruction, not nop.

Explicitly initialize the code zone with stops. Explicitly clear the
reclaimed portion of the method zone after a compaction.

Include the reclaimed portion of the method zone in the I-cache flush
after a compaction: no point in leaving it in cache since it isn't a
valid call/jump target.


Spur:
Maintain the survivor count on scavenge.

Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.

Spur Cogit: Support CompiledMethod indexing in genPrimitiveAt[Put].  Hence fix
the regression in at:[put:] whereby in Spur one could access the literals part
of a method as bytes.
Add a machine-code primitive for objectAt: to provide fast literal and header
access on Spur.

Add 16-bit indexability to Spur.  Generate slimmer code for
positive32BitValueOf: on 64-bit Spur.

Fix a bug with out-of-place two-way become, which got the hash copy the wrong
way round.  By default, the hash stays with the reference in two-way become.

Fix what appears to be a compiler bug with in-place two-way-become by treating
the headers to be swapped so that remembered flags are swapped and hash bits
are swapped if required. This fixes a bug with in-place two-way become of
objects that are the same size on the heap.  One object's contents would not
be updated correctly.

Implement ephemeron queue primitive.  Add an image flag that controls the
finalization support (StackInterpreter instVar newFinalization).  If unset,
finalization is as currently expected; WeakArray finalizes all WeakArrays in
its registries on each finalization (which does not scale!).  If set, then both
fired ephemerons and bereaved weak arrays are added to the finalization queue
and the finalization semaphore is signalled.  In this regime the image is
expected to send mourn to each element of the queue, and weak arrays will send
themselves finalize in mourn, side-stepping the finalizeValues steps and
rendering WeakArray's FinalizationDependents and WeakRegistry obsolete.
The bit is set via
    Smalltalk vmParameterAt: 48
              put: ((Smalltalk vmParameterAt: 48) bitOr: 64).


Slang:
Fix bad regression in type inference from VMMaker.oscog-eem.1587.
returnTypeForSend:in: can only default return types to sqInt for unknown
selectors.  The rewrite in VMMaker.oscog-eem.1587 inadvertently defaulted the
return type of known methods whose return type was yet to be determined to
sqInt.  The fix is to only default to sqInt if there is no known method for the
given selector.  This fixes, for instance, the weird flipping of the type of
32-bit Spur's headerWhileForwardingOf:,which should always be #sqLong.

Fix bad bug in type inferrence.  Avoid computing variable and return types
prematurely i.e. don't derive types from as-yet-untyped methods.

Fix baaaad bug in node:typeCompatibleWith:inliningInto:in: which was looking
up the type of the formal parameter in inlining in the target method, not the
method being inlined!


Newspeak:
Fix bug in MNU for cogged dynamic super sends - should start looking for
#doesNotUnderstand: in the superclass not the receiver class. Unify MNU
lookup between absent and present receiver sends as a result.

Further fix outer send MNU by not confusing lkupClass and lkupClassTag.
Push setting lkupClassTag down to clarify it is for new cache entries.


Plugins:
Fix the FilePlugin's unnecessary fullGC on Spur.
Include the file sync prim in the FilePrims plugin.

ThreadedFFIPlugin:
- ExternalAddress now are taken correctly (nor as ByteArray or Alien, because
  they are different beasts).  
- allow pushing of pointers to any type (into a ByteArray, an ExternalAddress
  or an Alien), to allow passing parameters style int*, float*, etc.
- allow reading in memory to allow read chunks of ByteArray

Added ThreadedFFIPlugin>>#primitiveLoadSymbolFromModule (copy and adapt from
IA32ABIPlugin).

Fix coercion problems on FFI plugin (IA32 & ARM)
- character were not correctly mapped back
- floats were not being well checked
- external addressed needs to be treated as aliens for the purpose of coercing
  them as pointers (bad regression by Eliot)

Alien Plugins:
Fix missing primitive failure for Alien typeAt: 0 [put:].
Add word accessors to Alien.

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Levente Uzonyi
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they
Mac only?

Levente


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Eliot Miranda-2


On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac only?

Oops.  Bugs in my upload scripts.  Adding the 64-bit linux VMs now.

Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM.

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Karl Ramberg
Cool. Looking forward to the WIN64 VM :-)

Best,
Karl

Best,
Karl

On Tue, Feb 16, 2016 at 2:23 AM, Eliot Miranda <[hidden email]> wrote:
 


On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac only?

Oops.  Bugs in my upload scripts.  Adding the 64-bit linux VMs now.

Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM.

_,,,^..^,,,_
best, Eliot




Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

marcel.taeumel
In reply to this post by Eliot Miranda-2
Hi Eliot,

sure. Tobias is about to fix some unicode issues in the Windows platform code for a Visual Studio build. 64-bits would be great! :-)

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Javier Diaz-Reinoso
In reply to this post by Eliot Miranda-2
I download from:
go to:
  Cog/build.macos32x86/squeak.cog.v3
and enter:
./mv
but after a few minutes this error:
make: *** [assert] Error 2
make: *** No rule to make target `build/vm/ADPCMCodecPlugin.lib', needed by `build/vm/Squeak'.  Stop.

I am missing some steps?, or the “compile your own VM” is not ready yet?

This is in a MacBook OS 10.11.3 (15D21) with XCode 7.2.1 (7C1002).

On Feb 15, 2016, at 20:23, Eliot Miranda <[hidden email]> wrote:



On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac only?

Oops.  Bugs in my upload scripts.  Adding the 64-bit linux VMs now.

Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM.

_,,,^..^,,,_
best, Eliot




Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Levente Uzonyi
In reply to this post by Eliot Miranda-2
I see the 64-bit Newspeak VMs, but not the ones for Squeak. Am I just
missing something?

Levente

On Mon, 15 Feb 2016, Eliot Miranda wrote:


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Eliot Miranda-2
In reply to this post by Javier Diaz-Reinoso
Hi Javier,

    I just updated the HowToBuild.  Try again and if you have problems please mail me a transcript of the session starting from your cd to the build directory and including a uname -a.  Thx

_,,,^..^,,,_ (phone)

On Feb 17, 2016, at 11:57 AM, Javier Diaz-Reinoso <[hidden email]> wrote:

I download from:
go to:
  Cog/build.macos32x86/squeak.cog.v3
and enter:
./mv
but after a few minutes this error:
make: *** [assert] Error 2
make: *** No rule to make target `build/vm/ADPCMCodecPlugin.lib', needed by `build/vm/Squeak'.  Stop.

I am missing some steps?, or the “compile your own VM” is not ready yet?

This is in a MacBook OS 10.11.3 (15D21) with XCode 7.2.1 (7C1002).

On Feb 15, 2016, at 20:23, Eliot Miranda <[hidden email]> wrote:



On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac only?

Oops.  Bugs in my upload scripts.  Adding the 64-bit linux VMs now.

Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM.

_,,,^..^,,,_
best, Eliot





Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Javier Diaz-Reinoso
I find the problem: I don’t load the files in the boot disk but in other HD (directory name: /Volumes/HD/Tools/Squeak/VM Cocoa/Cog ), when I download the files in a directory on the boot disk, the VM compile OK. 

So al least the scripts for ADPCMCodecPlugin fails when not in the boot disk, or perhaps the space in the path?, the build directory in the boot disk don’t have a space in the path.


On Feb 20, 2016, at 13:08, Eliot Miranda <[hidden email]> wrote:

Hi Javier,

    I just updated the HowToBuild.  Try again and if you have problems please mail me a transcript of the session starting from your cd to the build directory and including a uname -a.  Thx

_,,,^..^,,,_ (phone)

On Feb 17, 2016, at 11:57 AM, Javier Diaz-Reinoso <[hidden email]> wrote:

I download from:
go to:
  Cog/build.macos32x86/squeak.cog.v3
and enter:
./mv
but after a few minutes this error:
make: *** [assert] Error 2
make: *** No rule to make target `build/vm/ADPCMCodecPlugin.lib', needed by `build/vm/Squeak'.  Stop.

I am missing some steps?, or the “compile your own VM” is not ready yet?

This is in a MacBook OS 10.11.3 (15D21) with XCode 7.2.1 (7C1002).

On Feb 15, 2016, at 20:23, Eliot Miranda <[hidden email]> wrote:



On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac only?

Oops.  Bugs in my upload scripts.  Adding the 64-bit linux VMs now.

Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM.

_,,,^..^,,,_
best, Eliot







Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Eliot Miranda-2
Hi Javier,



On Feb 20, 2016, at 2:56 PM, Javier Diaz-Reinoso <[hidden email]> wrote:

I find the problem: I don’t load the files in the boot disk but in other HD (directory name: /Volumes/HD/Tools/Squeak/VM Cocoa/Cog ), when I download the files in a directory on the boot disk, the VM compile OK. 

So al least the scripts for ADPCMCodecPlugin fails when not in the boot disk, or perhaps the space in the path?, the build directory in the boot disk don’t have a space in the path.

I bet it's a space in the path.  What's the name of your non-boot disc?

How good are you at editing makefiles?  If you're ok with gnu make fancy trying to fix them?  ;-)



On Feb 20, 2016, at 13:08, Eliot Miranda <[hidden email]> wrote:

Hi Javier,

    I just updated the HowToBuild.  Try again and if you have problems please mail me a transcript of the session starting from your cd to the build directory and including a uname -a.  Thx

_,,,^..^,,,_ (phone)

On Feb 17, 2016, at 11:57 AM, Javier Diaz-Reinoso <[hidden email]> wrote:

I download from:
go to:
  Cog/build.macos32x86/squeak.cog.v3
and enter:
./mv
but after a few minutes this error:
make: *** [assert] Error 2
make: *** No rule to make target `build/vm/ADPCMCodecPlugin.lib', needed by `build/vm/Squeak'.  Stop.

I am missing some steps?, or the “compile your own VM” is not ready yet?

This is in a MacBook OS 10.11.3 (15D21) with XCode 7.2.1 (7C1002).

On Feb 15, 2016, at 20:23, Eliot Miranda <[hidden email]> wrote:



On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac only?

Oops.  Bugs in my upload scripts.  Adding the 64-bit linux VMs now.

Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM.

_,,,^..^,,,_
best, Eliot








Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Javier Diaz-Reinoso

On Feb 20, 2016, at 21:23, Eliot Miranda <[hidden email]> wrote:

Hi Javier,



On Feb 20, 2016, at 2:56 PM, Javier Diaz-Reinoso <[hidden email]> wrote:

I find the problem: I don’t load the files in the boot disk but in other HD (directory name: /Volumes/HD/Tools/Squeak/VM Cocoa/Cog ), when I download the files in a directory on the boot disk, the VM compile OK. 

So al least the scripts for ADPCMCodecPlugin fails when not in the boot disk, or perhaps the space in the path?, the build directory in the boot disk don’t have a space in the path.

I bet it's a space in the path.  What's the name of your non-boot disc?

Yes It’s the space.

How good are you at editing makefiles?  If you're ok with gnu make fancy trying to fix them?  ;-)

Too hard, better you put a warning in the “HowToBuild” file.



On Feb 20, 2016, at 13:08, Eliot Miranda <[hidden email]> wrote:

Hi Javier,

    I just updated the HowToBuild.  Try again and if you have problems please mail me a transcript of the session starting from your cd to the build directory and including a uname -a.  Thx

_,,,^..^,,,_ (phone)

On Feb 17, 2016, at 11:57 AM, Javier Diaz-Reinoso <[hidden email]> wrote:

I download from:
go to:
  Cog/build.macos32x86/squeak.cog.v3
and enter:
./mv
but after a few minutes this error:
make: *** [assert] Error 2
make: *** No rule to make target `build/vm/ADPCMCodecPlugin.lib', needed by `build/vm/Squeak'.  Stop.

I am missing some steps?, or the “compile your own VM” is not ready yet?

This is in a MacBook OS 10.11.3 (15D21) with XCode 7.2.1 (7C1002).

On Feb 15, 2016, at 20:23, Eliot Miranda <[hidden email]> wrote:



On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac only?

Oops.  Bugs in my upload scripts.  Adding the 64-bit linux VMs now.

Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM.

_,,,^..^,,,_
best, Eliot