Vm-dev July 2020

vm-dev@lists.squeakfoundation.org

21 participants
122 discussions

VM Maker: VMMaker.oscog-eem.2774.mcz
by commits＠source.squeak.org 12 Jul '20

12 Jul '20

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2774.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2774 Author: eem Time: 11 July 2020, 6:50:06.654573 pm UUID: f6fac8da-39c5-413a-9dec-fd46dade5a44 Ancestors: VMMaker.oscog-eem.2773 Fic a warning from compiling the cogit. =============== Diff against VMMaker.oscog-eem.2773 =============== Item was changed: ----- Method: Cogit>>genInvokeInterpretTrampoline (in category 'initialization') ----- genInvokeInterpretTrampoline "Switch to the C stack (do *not* save the Smalltalk stack pointers; this is the caller's responsibility), and invoke interpret PDQ." | startAddress | <inline: false> startAddress := methodZoneBase. self zeroOpcodeIndex. backEnd hasVarBaseRegister ifTrue: [self MoveCq: self varBaseAddress R: VarBaseReg]. "Must happen first; value may be used in genLoadStackPointers" cFramePointerInUse ifTrue: [backEnd genLoadCStackPointers] ifFalse: [backEnd genLoadCStackPointer]. "Sideways call interpret so that the stack looks correct, for exception handling etc" backEnd genMarshallNArgs: 0 arg: nil arg: nil arg: nil arg: nil. backEnd hasLinkRegister ifTrue: [self MoveAw: coInterpreter cReturnAddressAddress R: LinkReg] ifFalse: [self MoveAw: coInterpreter cReturnAddressAddress R: ABIResultReg. backEnd genSubstituteReturnAddressR: ABIResultReg]. self JumpFullRT: (self cCode: [#interpret asUnsignedInteger] inSmalltalk: [self simulatedTrampolineFor: #interpret]). self outputInstructionsForGeneratedRuntimeAt: startAddress. self recordGeneratedRunTime: 'ceInvokeInterpret' address: startAddress. + ^self cCoerceSimple: startAddress to: #'void (*)(void)'! - ^startAddress!

1 0

[OpenSmalltalk/opensmalltalk-vm] ba263d: CogVM source as per ClosedVMMaker-eem.95
by Eliot Miranda 12 Jul '20

12 Jul '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: ba263dfef8d925c311e86f166d01811b1c0032c2 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ba263dfef8d925c311… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-07-11 (Sat, 11 Jul 2020) Changed paths: M build.macos32x86/makeproduct M nsspur64src/vm/cogitARMv8.c M spur64src/vm/cogitARMv8.c M spurlowcode64src/vm/cogitARMv8.c M spursista64src/vm/cogitARMv8.c Log Message: ----------- CogVM source as per ClosedVMMaker-eem.95 ARMv8 Cogit: Add a missing type declaration to noteFollowingConditionalBranch: Better order the two multiplies in MulOverflowRRR.

1 0

[OpenSmalltalk/opensmalltalk-vm] 41115d: CogVM source as per VMMaker.oscog-eem.2773/ClosedV...
by Eliot Miranda 09 Jul '20

09 Jul '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 41115d41e24c7c6d9b1ab059fe312dbdbfb3848c https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/41115d41e24c7c6d9b… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-07-09 (Thu, 09 Jul 2020) Changed paths: M nsspur64src/vm/cogit.h M nsspur64src/vm/cogitARMv8.c 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 spur64src/vm/cogit.h M spur64src/vm/cogitARMv8.c M spur64src/vm/cogitX64SysV.c M spur64src/vm/cogitX64WIN64.c M spurlowcode64src/vm/cogit.h M spurlowcode64src/vm/cogitARMv8.c 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/cogitARMv8.c 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/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.2773/ClosedVMMaker-eem.93 Cogit: Fix the use of the undefined ceFlushDCache function when DUAL_WRITE_CODE_ZONE is not defined and flushDCacheFrom:to: is not a no-op. Make sure any generated check features, and the generated run-time are cache flushed before use. Move maybeGenerateCheckLZCNT later initializeCodeZoneFrom:upTo:; its result is not used until compiling primitives.

1 0

VM Maker: VMMaker.oscog-eem.2773.mcz
by commits＠source.squeak.org 09 Jul '20

09 Jul '20

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2773.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2773 Author: eem Time: 9 July 2020, 10:46:46.555474 am UUID: 3c51054d-e839-4959-b3e1-562845a4fa54 Ancestors: VMMaker.oscog-eem.2772 Cogit: Fix the use of the undefined ceFlushDCache function when DUAL_WRITE_CODE_ZONE is not defined and flushDCacheFrom:to: is not a no-op. Make sure any generated check features, and the generated run-time are cache flushed before use. Move maybeGenerateCheckLZCNT later initializeCodeZoneFrom:upTo:; its result is not used until compiling primitives. =============== Diff against VMMaker.oscog-eem.2772 =============== Item was added: + ----- Method: CogIA32Compiler>>initialFlushICacheFrom:to: (in category 'inline cacheing') ----- + initialFlushICacheFrom: startAddress "<Integer>" to: endAddress "<Integer>" + "This must be implemented only if a back end defines any of the following as non-zero: + numCheckFeaturesOpcodes + numDCacheFlushOpcodes + numICacheFlushOpcode. + + This is a no-op on IA32." + <cmacro: '(me,startAddress,endAddress) 0'>! Item was changed: ----- Method: Cogit>>initializeCodeZoneFrom:upTo: (in category 'initialization') ----- initializeCodeZoneFrom: startAddress upTo: endAddress <api> self initializeBackend. self sqMakeMemoryExecutableFrom: startAddress To: endAddress CodeToDataDelta: (self cppIf: #DUAL_MAPPED_CODE_ZONE ifTrue: [self addressOf: codeToDataDelta put: [:v| codeToDataDelta := v]] ifFalse: [nil]). backEnd stopsFrom: startAddress to: endAddress - 1. self cCode: '' inSmalltalk: [self initializeProcessor. backEnd stopsFrom: 0 to: guardPageSize - 1]. codeBase := methodZoneBase := startAddress. minValidCallAddress := (codeBase min: coInterpreter interpretAddress) min: coInterpreter primitiveFailAddress. methodZone manageFrom: methodZoneBase to: endAddress. self assertValidDualZone. self maybeGenerateCheckFeatures. - self maybeGenerateCheckLZCNT. self maybeGenerateCacheFlush. + self maybeGenerateCheckLZCNT. self generateVMOwnerLockFunctions. self genGetLeafCallStackPointers. self generateStackPointerCapture. self generateTrampolines. self computeEntryOffsets. self computeFullBlockEntryOffsets. self generateClosedPICPrototype. self alignMethodZoneBase. + "None of the above is executed beyond ceCheckFeatures, so a bulk flush now is the leanest thing to do." + backEnd flushICacheFrom: startAddress to: methodZoneBase asUnsignedInteger. - "None of the above is executed beyond ceCheckFeatures & ceCheckLZCNTFunction, - so a bulk flush now is the leanest thing to do." self maybeFlushWritableZoneFrom: startAddress to: methodZoneBase asUnsignedInteger. + "Repeat so that now the methodZone ignores the generated run-time." - "repeat so that now the methodZone ignores the generated run-time" methodZone manageFrom: methodZoneBase to: endAddress. + "N.B. this is assumed to be the last thing done in initialization; see Cogit>>initialized. + This is done only to compute openPICSize; the generated code is discarded." - "N.B. this is assumed to be the last thing done in initialization; see Cogit>>initialized" self generateOpenPICPrototype! Item was changed: ----- Method: Cogit>>maybeFlushWritableZoneFrom:to: (in category 'generate machine code - dual mapped zone support') ----- maybeFlushWritableZoneFrom: startAddress to: endAddress "If there is a dual mapped code zone (the normal zone but marked with read/execute, and a read/write zone codeToDataDelta bytes away) then the data cache for the read/write zone must be flushed, and the data cache for the read/execute zone must be invalidated, for the Cogit to see the same values in both zones after a write to the read/write zone." <var: 'startAddress' type: #usqInt> <var: 'endAddress' type: #usqInt> + <inline: #always> + self cppIf: #DUAL_MAPPED_CODE_ZONE + ifTrue: + [codeToDataDelta > 0 ifTrue: + [backEnd flushDCacheFrom: startAddress to: endAddress]]! - codeToDataDelta > 0 ifTrue: - [backEnd flushDCacheFrom: startAddress to: endAddress]! Item was changed: ----- Method: Cogit>>maybeGenerateCheckFeatures (in category 'initialization') ----- maybeGenerateCheckFeatures | startAddress | <inline: true> backEnd numCheckFeaturesOpcodes > 0 ifTrue: [self allocateOpcodes: backEnd numCheckFeaturesOpcodes bytecodes: 0. startAddress := methodZoneBase. backEnd generateCheckFeatures. self outputInstructionsForGeneratedRuntimeAt: startAddress. self recordGeneratedRunTime: 'ceCheckFeaturesFunction' address: startAddress. + ceCheckFeaturesFunction := self cCoerceSimple: startAddress to: #'usqIntptr_t (*)(void)'. + backEnd initialFlushICacheFrom: startAddress to: methodZoneBase]! - ceCheckFeaturesFunction := self cCoerceSimple: startAddress to: #'usqIntptr_t (*)(void)']! Item was removed: - ----- Method: Cogit>>processorHasLZCNTSupport (in category 'initialization') ----- - processorHasLZCNTSupport - <option: #DPFPReg0> - <inline: true> - ^backEnd hasLZCNTInstructions!

1 0

Possible bug in FFICallbackThunk class>>#freeBlockInExecutablePage:
by Bob Westergaard 08 Jul '20

08 Jul '20

Hi, I believe there is a bug in FFICallbackThunk class>>#freeBlockInExecutablePage: (in Alien-Core). If there are multiple pages allocated, it is possible that the address comparison with the end of the executable page will mistakenly pass. What will end up happening is that you'll get an #unsignedByteAt:put: failure ('bad index') error during finalization when the section of that page is being marked as free. For example, I saw the failure where the address being freed was 1785856 (16r1B4000). There was a page at 16r1B3000, so the check for this address evaluates to true. This ends up trying to use 4097 as the index (dataSize is 4096 here). (address >= alienAddress and: [alienAddress + alienPage dataSize >= address]) ifTrue: [alienPage unsignedByteAt: address - alienAddress + 1 put: 0. ... The newest version I found on squeak source was Alien-Core-nice.104 and the test is the same. I changed >= to > here and the problem went away for me: (address >= alienAddress and: [alienAddress + alienPage dataSize > address]) ifTrue: Is my reading of this correct? Since we are here, why do #initializeX64 and #initializeX64Win64 end their methods with sending #primThunkEntryAddress and doing nothing with the returned result? Is there a side-effect going on here? It looks to me like a possible copy and paste error. Regards, -- Bob

2 1

Errored: OpenSmalltalk/opensmalltalk-vm#2103 (Cog - b09b99f)
by Travis CI 07 Jul '20

07 Jul '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #2103 Status: Errored Duration: 45 mins and 31 secs Commit: b09b99f (Cog) Author: Eliot Miranda Message: CogVM source as per VMMaker.oscog-eem.2772 VM Parameters primitive(s). Fix the issue with the allocation failure test on 32-bit systems. It really is a VM bug that parameter #67 (maxOldSpaceSize) must be a SmallInteger. It should be a positive machine integer. View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/5d03fae3e9f0...b0… View the full build log and details: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/builds/70552302… -- You can unsubscribe from build emails from the OpenSmalltalk/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8795279&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

4 4

Fwd: [Lse-consortium] [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508)
by Nicolas Cellier 07 Jul '20

07 Jul '20

Hmm, I forward this because I thought that I answered on vm-dev... but of course, pharo team cannot follow this ML for obvious reasons, and prefer obscure ML not even listed here https://lists.gforge.inria.fr/mailman/listinfo, maybe a private ML unless it's a typo? ---------- Forwarded message --------- De : Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: dim. 28 juin 2020 à 15:52 Subject: Re: [Lse-consortium] [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: Don't record SQDragLeave when XdndDrop is handled (#508) To: Stéphane Ducasse <stephane.ducasse(a)inria.fr> Cc: Mailinglist for consortium engineering < lse-consortium(a)lists.gforge.inria.fr> Hi Stephane, please read carefully 'Ridiculous failure...' thread on OpenSmalltalk VM dev mailing list. http://forum.world.st/Ridiculous-failures-td5118674.html > The job exceeded the maximum log length, and has been terminated. We know that the CI set up is not good, it leads to these ridiculous failures. Solutions have been sketched for a long time, but never implemented in the original opensmalltalk-vm repository. https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/386 And of course, this kind of solution has been implemented in the pharo fork meanwhile... So a problem coming from the way pharo is built on opensmalltalk, is solved only in the fork shortly after the fork. A sign that it was not so complex to solve after all? This change was not contributed back. Why is that? Do you think it's a good thing to let pharo build rotting in original repo? Yes, this attitude upsets me. I helped fixing pharo builds upstream, "cleaning after the dog of someone else" as I said. But no one in Pharo community will never help and contribute back? Or take at least time to answer when I request support? You know the French saying, "trop bon, trop con", that's exactly how I feel at the moment. Le dim. 28 juin 2020 à 12:15, Stéphane Ducasse <stephane.ducasse(a)inria.fr> a écrit : > Hi nicolas > > When did you requested something? and that we did not react. > Most of us are in following the vm-dev for obvious reason. > We cannot be insulted on regular basis and be treated as guys that do not > understand > on discord. > For my particular case, I decided that pasted 50 I do not accept this > anymore. > > S. > > > On 27 Jun 2020, at 23:47, Christophe Demarey <Christophe.Demarey(a)inria.fr> > wrote: > > In case you missed it: > > Début du message réexpédié : > > *De: *Nicolas Cellier <notifications(a)github.com> > *Objet: **Rép : [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] sqUnixXdnd: > Don't record SQDragLeave when XdndDrop is handled (#508)* > *Date: *27 juin 2020 à 21:42:02 UTC+2 > *À: *OpenSmalltalk/opensmalltalk-vm <opensmalltalk-vm(a)noreply.github.com> > *Cc: *Subscribed <subscribed(a)noreply.github.com> > *Répondre à: *OpenSmalltalk/opensmalltalk-vm < > reply+AIJPEWYWOOPPNJ5IXVGPTG55AOBAVEVBNHHCMBT3BA(a)reply.github.com>, Open > Smalltalk Virtual Machine Development Discussion < > vm-dev(a)lists.squeakfoundation.org> > > Ideally we should do it on an old version of pharo too (7?), but at one > moment, pharo people shall help us to help them, and this is not the trend. > The INRIA team forked, and when I request community help on > Opensmalltalk-vm-dev ML, I ear nothing but a big silence, I guess no one is > interested. Newspeak sounds less like a problem, because they use their own > form of FFI for windows system integration rather than plugin. > > > _______________________________________________ > Lse-consortium mailing list > Lse-consortium(a)lists.gforge.inria.fr > https://lists.gforge.inria.fr/mailman/listinfo/lse-consortium > > > -------------------------------------------- > Stéphane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

1 0

Passed: OpenSmalltalk/opensmalltalk-vm#2104 (Cog - 839a5ca)
by Travis CI 07 Jul '20

07 Jul '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #2104 Status: Passed Duration: 2 hrs, 42 mins, and 50 secs Commit: 839a5ca (Cog) Author: Eliot Miranda Message: MacOS: Revise the install_name_tool machinations in the light of experience with the Terf plugins and examination of e.g. Xcode,app. When including dylibs from elsewhere in Contents/Frameworks they should have an id of @rpath/foo.M.dylib and access any dylibs they load from Contents/Frameworks should also be named @rpath/bar.N.dylib, etc. Likewise the executable should include an rpath for Contents/Resources (we'd like it to be Contents/PlugIns but this seems to break something), and Contents/Frameworks. It turns out that Xcode.app uses both @executable_path/../Frameworks & @executable_path/../PlugIns. We're close but not quite there yet. Add similar debug printing to tryLoadingLinked as is in tryLoadingInternals. View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/b09b99f489e7...83… View the full build log and details: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/builds/70563609… -- You can unsubscribe from build emails from the OpenSmalltalk/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8795279&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

[OpenSmalltalk/opensmalltalk-vm] 839a5c: MacOS:
by Eliot Miranda 07 Jul '20

07 Jul '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 839a5cab095a76160d4b66c2fcd6e13d898ea0c9 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/839a5cab095a76160d… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-07-06 (Mon, 06 Jul 2020) Changed paths: M build.macos32x86/common/Makefile.app M build.macos32x86/common/Makefile.flags M build.macos32x86/common/Makefile.lib.extra M build.macos64x64/common/Makefile.app M build.macos64x64/common/Makefile.flags M build.macos64x64/common/Makefile.lib.extra M platforms/iOS/vm/OSX/sqMacUnixExternalPrims.m Log Message: ----------- MacOS: Revise the install_name_tool machinations in the light of experience with the Terf plugins and examination of e.g. Xcode,app. When including dylibs from elsewhere in Contents/Frameworks they should have an id of @rpath/foo.M.dylib and access any dylibs they load from Contents/Frameworks should also be named @rpath/bar.N.dylib, etc. Likewise the executable should include an rpath for Contents/Resources (we'd like it to be Contents/PlugIns but this seems to break something), and Contents/Frameworks. It turns out that Xcode.app uses both @executable_path/../Frameworks & @executable_path/../PlugIns. We're close but not quite there yet. Add similar debug printing to tryLoadingLinked as is in tryLoadingInternals.

1 0

[OpenSmalltalk/opensmalltalk-vm] b09b99: CogVM source as per VMMaker.oscog-eem.2772
by Eliot Miranda 06 Jul '20

06 Jul '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: b09b99f489e7e97f1ba707124865e43aaa93fe6b https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/b09b99f489e7e97f1b… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-07-06 (Mon, 06 Jul 2020) Changed paths: M nsspur64src/vm/cogit.h M nsspur64src/vm/cointerp.c M nsspur64src/vm/cointerp.h M nsspur64src/vm/gcc3x-cointerp.c M nsspursrc/vm/cogit.h M nsspursrc/vm/cointerp.c M nsspursrc/vm/cointerp.h M nsspursrc/vm/gcc3x-cointerp.c M nsspurstack64src/vm/gcc3x-interp.c M nsspurstack64src/vm/interp.c M nsspurstacksrc/vm/gcc3x-interp.c M nsspurstacksrc/vm/interp.c M spur64src/vm/cogit.h M spur64src/vm/cointerp.c M spur64src/vm/cointerp.h M spur64src/vm/cointerpmt.c M spur64src/vm/cointerpmt.h M spur64src/vm/gcc3x-cointerp.c M spur64src/vm/gcc3x-cointerpmt.c M spurlowcode64src/vm/cogit.h M spurlowcode64src/vm/cogitARMv8.c M spurlowcode64src/vm/cogitX64SysV.c M spurlowcode64src/vm/cogitX64WIN64.c M spurlowcode64src/vm/cointerp.c M spurlowcode64src/vm/cointerp.h M spurlowcode64src/vm/gcc3x-cointerp.c M spurlowcodesrc/vm/cogit.h M spurlowcodesrc/vm/cogitARMv5.c M spurlowcodesrc/vm/cogitIA32.c M spurlowcodesrc/vm/cogitMIPSEL.c M spurlowcodesrc/vm/cointerp.c M spurlowcodesrc/vm/cointerp.h M spurlowcodesrc/vm/gcc3x-cointerp.c M spurlowcodestack64src/vm/gcc3x-interp.c M spurlowcodestack64src/vm/interp.c M spurlowcodestacksrc/vm/gcc3x-interp.c M spurlowcodestacksrc/vm/interp.c M spursista64src/vm/cogit.h M spursista64src/vm/cointerp.c M spursista64src/vm/cointerp.h M spursista64src/vm/gcc3x-cointerp.c M spursistasrc/vm/cogit.h M spursistasrc/vm/cointerp.c M spursistasrc/vm/cointerp.h M spursistasrc/vm/gcc3x-cointerp.c M spursrc/vm/cogit.h M spursrc/vm/cointerp.c M spursrc/vm/cointerp.h M spursrc/vm/cointerpmt.c M spursrc/vm/cointerpmt.h M spursrc/vm/gcc3x-cointerp.c M spursrc/vm/gcc3x-cointerpmt.c M spurstack64src/vm/gcc3x-interp.c M spurstack64src/vm/interp.c M spurstacksrc/vm/gcc3x-interp.c M spurstacksrc/vm/interp.c M src/vm/cogit.h M src/vm/cointerp.c M src/vm/cointerp.h M src/vm/cointerpmt.c M src/vm/cointerpmt.h M src/vm/gcc3x-cointerp.c M src/vm/gcc3x-cointerpmt.c M stacksrc/vm/gcc3x-interp.c M stacksrc/vm/interp.c Log Message: ----------- CogVM source as per VMMaker.oscog-eem.2772 VM Parameters primitive(s). Fix the issue with the allocation failure test on 32-bit systems. It really is a VM bug that parameter #67 (maxOldSpaceSize) must be a SmallInteger. It should be a positive machine integer.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev July 2020