[OpenSmalltalk/opensmalltalk-vm] 18c03b: CogVM source as per VMMaker.oscog-eem.2262

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

[OpenSmalltalk/opensmalltalk-vm] 18c03b: CogVM source as per VMMaker.oscog-eem.2262

  Branch: refs/heads/Cog
  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
  Commit: 18c03b6b8e57f62d747068635280cce0b6d0d078
  Author: Eliot Miranda <[hidden email]>
  Date:   2017-08-14 (Mon, 14 Aug 2017)

  Changed paths:
    M nsspur64src/vm/cogit.h
    M nsspur64src/vm/cogitX64SysV.c
    M nsspur64src/vm/cogitX64WIN64.c
    M nsspursrc/vm/cogit.h
    M nsspursrc/vm/cogitARMv5.c
    M nsspursrc/vm/cogitIA32.c
    M nsspursrc/vm/cogitMIPSEL.c
    M nsspurstack64src/vm/gcc3x-interp.c
    M nsspurstack64src/vm/interp.c
    M spur64src/vm/cogit.h
    M spur64src/vm/cogitX64SysV.c
    M spur64src/vm/cogitX64WIN64.c
    M spurlowcode64src/vm/cogit.h
    M spurlowcode64src/vm/cogitX64SysV.c
    M spurlowcode64src/vm/cogitX64WIN64.c
    M spurlowcodesrc/vm/cogit.h
    M spurlowcodesrc/vm/cogitARMv5.c
    M spurlowcodesrc/vm/cogitIA32.c
    M spurlowcodesrc/vm/cogitMIPSEL.c
    M spursista64src/vm/cogit.h
    M spursista64src/vm/cogitX64SysV.c
    M spursista64src/vm/cogitX64WIN64.c
    M spursistasrc/vm/cogit.h
    M spursistasrc/vm/cogitARMv5.c
    M spursistasrc/vm/cogitIA32.c
    M spursistasrc/vm/cogitMIPSEL.c
    M spursrc/vm/cogit.h
    M spursrc/vm/cogitARMv5.c
    M spursrc/vm/cogitIA32.c
    M spursrc/vm/cogitMIPSEL.c
    M src/plugins/LargeIntegers/LargeIntegers.c
    M src/vm/cogit.h
    M src/vm/cogitARMv5.c
    M src/vm/cogitIA32.c
    M src/vm/cogitMIPSEL.c

  Log Message:
  CogVM source as per VMMaker.oscog-eem.2262

Modify the profiling primitive cogCodeConstituents: to be able to differentiate
the closedPICs from the openPICs in the profiling report

LargeIntegers plugin
Fix the crash for 2009 nthRoot: 100000 due to digitDivLarge:with:negative: not
checking if allocations fail.  The example produces 600k byte long integers and
so provokes plenty of allocation failures.

In addition mark some support methods as <inline: #always> to eliminate their
unnecessary uninlined versions.