Vm-dev September 2016

vm-dev@lists.squeakfoundation.org

30 participants
102 discussions

[OpenSmalltalk/opensmalltalk-vm] f0ee28: Modify gitci script to check for "unofficial files...
by GitHub 30 Sep '16

30 Sep '16

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: f0ee288e7eaf6ea44d7b15db8b95f19fefc08bc3 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f0ee288e7eaf6ea44d… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2016-09-30 (Fri, 30 Sep 2016) Changed paths: M scripts/gitci M spursrc/vm/cogit.h M spursrc/vm/cogitARMv5.c M spursrc/vm/cogitIA32.c M spursrc/vm/cogitMIPSEL.c M spursrc/vm/cogmethod.h M spursrc/vm/cointerp.c M spursrc/vm/cointerp.h M spursrc/vm/gcc3x-cointerp.c M spursrc/vm/interp.h M spursrc/vm/vmCallback.h M src/plugins/SqueakFFIPrims/ARM32FFIPlugin.c M src/plugins/SqueakFFIPrims/IA32FFIPlugin.c M src/plugins/VMProfileMacSupportPlugin/VMProfileMacSupportPlugin.c Log Message: ----------- Modify gitci script to check for "unofficial files" (files generated from modified Monticello packages). Regenerate and commit spursrc and FFI plgin code as per VMMaker.oscog-eem.1950. Regenerate VMProfileMacSupportPlugin as per VMMaker.oscog-eem.1953.

1 0

I want to add commit id to VM version
by Esteban Lorenzano 30 Sep '16

30 Sep '16

Hi, I would like to add also commit id to current VM version. We now have this: VM: 201609281647 https://github.com/estebanlm/opensmalltalk-vm.git $ Date: Wed Sep 28 18:47:01 2016 +0200 $ Plugins: 201609281647 https://github.com/estebanlm/opensmalltalk-vm.git $ And that’s ok, of course. But I would want also to have the commit version (it makes easier some queries). Something like this: VM: 201609281647 https://github.com/estebanlm/opensmalltalk-vm.git $ Date: Wed Sep 28 18:47:01 2016 +0200 $ Plugins: 201609281647 https://github.com/estebanlm/opensmalltalk-vm.git $ Commit: 09aaed https://github.com/estebanlm/opensmalltalk-vm.git $ What do you think, may I proceed? Cheers! Esteban

4 5

[OpenSmalltalk/opensmalltalk-vm] 4fb291: In the VM profiler, pin 64-bit pcs outside 32-bit ...
by GitHub 30 Sep '16

30 Sep '16

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 4fb291f1485329db449caaa0b274d88fc8cb5ab1 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/4fb291f1485329db44… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2016-09-30 (Fri, 30 Sep 2016) Changed paths: M platforms/unix/vm/sqUnixVMProfile.c Log Message: ----------- In the VM profiler, pin 64-bit pcs outside 32-bit range to max 32-bit val.

1 0

[OpenSmalltalk/opensmalltalk-vm] 3b4b6b: Allow 32-bit PC samples on 64-bit platforms in the...
by GitHub 30 Sep '16

30 Sep '16

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 3b4b6b30caea8fb139d2fb8b820c9033c2b88db5 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3b4b6b30caea8fb139… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2016-09-29 (Thu, 29 Sep 2016) Changed paths: M build.linux32ARMv6/HowToBuild M platforms/unix/vm/sqUnixVMProfile.c Log Message: ----------- Allow 32-bit PC samples on 64-bit platforms in the VMProfiler, defaulting to 32-bit samples on Mac OS X. Update instructions for instaling Open GL on Raspbian (Debian).

2 1

Re: [Pharo-dev] testing sista
by Eliot Miranda 30 Sep '16

30 Sep '16

Hi Clément, > On Sep 30, 2016, at 6:44 AM, Clément Bera <bera.clement(a)gmail.com> wrote: > > Hi. > > In short: > normally you don't, but for some reasons right now you do. Try a VM from here [1]. > > In long: > Normally you need a VM with the following slang to C compilation settings: > MULTIPLEBYTECODESETS true > bytecodeTableInitializer initializeBytecodeTableForSqueakV3PlusClosuresSistaV1Hybrid > which has been added recently to multiple VM builds, including the Pharo build if I am correct. > > The latest Pharo VM on files.pharo.org answers true to "Smalltalk vm supportsMultipleBytecodeSets", so it should be fine... > But, when I tried to run code with new bytecode set, it does not work indeed. It's disconcerting that this is so mysterious. - does an assert VM show up anything? - is it a regression from integrating Lowcode? - if you diff the generated code and try and filter out the Lowcode signal has anything changed? - does the Sista simulator work? - can we get help to produce a test suite? - what other questions should we be asking? > > So... > I've just compiled another VM to check and it could run the image. > I've just checked with the VM from openSmalltalk [1] and both pharo.cog.spur and squeak.cog.spur could run the Pharo image with both bytecode set and full blocks. > It's not clear pharo.cog.spur is a complete Pharo VM as the migration process to opensmalltalk VM is still in progress, it may be a squeak VM with part of the extra Pharo plugins. > > I believe something is temporarily wrong during the opensmalltalk pharo vm migration. I would recommend to use a VM from bintray to test those features until the migration is over. > On the openSmalltalkVM git [2] you have a link by clinking "download" to the latest bintray releases. Those releases are built automatically and very frequently. > > [1] https://bintray.com/opensmalltalk/vm/cog/201609292318#files/ > [2] https://github.com/OpenSmalltalk/opensmalltalk-vm > >> On Fri, Sep 30, 2016 at 2:54 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> Do we need a special vm for testing sista bytecode backend? >> I enabled sista in the compiler settings and evaluating >> >> [ ] class >> >> crashes the vm. >> >> >> nicolai >

2 1

ARM 7hf builds
by KenD 30 Sep '16

30 Sep '16

Greetings, opensmalltalk.org seems to be lacking in arm7 builds. In particular, I would like to see: cog_linux32ARMv7_squeak.cog.spur_*.tar.gz Any chance for this? Thanks much, -KenD

5 5

Re: [OpenSmalltalk/opensmalltalk-vm] added prepare-rpi.sh with all pre-reqs to build an ARMv6 (#67)
by Eliot Miranda 29 Sep '16

29 Sep '16

Hi Esteban, (skip to the bottom for the good news :-) ) when I try the install part of prepare.rpi.sh I get this: sudo apt-get install -yq --no-install-suggests --no-install-recommends --force-yes \ gcc-arm-linux-gnueabi \ gcc-arm-linux-gnueabihf \ qemu-system \ qemu-system-arm \ qemu-user \ qemu-user-static \ sbuild \ schroot \ scratchbox2 \ debootstrap \ zlib1g:i386 \ libstdc++6:i386 \ libffi-dev:i386 \ libffi6:i386 \ libssl1.0.0:i386 \ libbz2-1.0:i386 \ libc6-dev-i386 \ libc6:i386 \ libexpat1:i386 \ libtinfo5:i386 \ binfmt-support \ build-essential \ python-dev \ libffi-dev \ zlib1g-dev Reading package lists... Building dependency tree... Reading state information... E: Unable to locate package gcc-arm-linux-gnueabi E: Unable to locate package gcc-arm-linux-gnueabihf E: Unable to locate package qemu-system-arm E: Unable to locate package scratchbox2 E: Unable to locate package zlib1g E: Unable to locate package libstdc++6 E: Couldn't find any package by regex 'libstdc++6' E: Unable to locate package libffi-dev E: Unable to locate package libffi6 E: Unable to locate package libssl1.0.0 E: Couldn't find any package by regex 'libssl1.0.0' E: Unable to locate package libbz2-1.0 E: Couldn't find any package by regex 'libbz2-1.0' E: Unable to locate package libc6-dev-i386 E: Unable to locate package libc6 E: Unable to locate package libexpat1 E: Unable to locate package libtinfo5 BTW, your chroot code inside prepare.rpi.sh is in terms of your username. Perhaps you could pull that out into a parameterised script so you say, e.g. prepare-rpi-chroot esteban so that USER is an argument instead of being baked in. Anyway, I can build the pharo VM, so a high thank you for that! On Tue, Sep 27, 2016 at 1:18 PM, Esteban Lorenzano <notifications(a)github.com > wrote: > auto-merge because is not a relevant change. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/67#issuecomment-2499…>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/APHa0BtsotHCVsLWRr_ft7jxH…> > . > -- _,,,^..^,,,_ best, Eliot

1 0

VM Maker: VMMaker.oscog-EstebanLorenzano.1955.mcz
by commits＠source.squeak.org 29 Sep '16

29 Sep '16

Esteban Lorenzano uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-EstebanLorenzano.1955.mcz ==================== Summary ==================== Name: VMMaker.oscog-EstebanLorenzano.1955 Author: EstebanLorenzano Time: 29 September 2016, 2:20:59.672732 pm UUID: cb359d33-3a8c-4649-a89e-448090843137 Ancestors: VMMaker.oscog-cb.1954 fetch of sourceHandle may fail, provocking an crash on Pharo. Adding a simple guard to prevent it (as suggested by Peter Uhnak) =============== Diff against VMMaker.oscog-cb.1954 =============== Item was changed: ----- Method: BitBltSimulation>>lockSurfaces (in category 'surface support') ----- lockSurfaces "Get a pointer to the bits of any OS surfaces." "Notes: * For equal source/dest handles only one locking operation is performed. This is to prevent locking of overlapping areas which does not work with certain APIs (as an example, DirectDraw prevents locking of overlapping areas). A special case for non-overlapping but equal source/dest handle would be possible but we would have to transfer this information over to unlockSurfaces somehow (currently, only one unlock operation is performed for equal source and dest handles). Also, this would require a change in the notion of ioLockSurface() which is right now interpreted as a hint and not as a requirement to lock only the specific portion of the surface. * The arguments in ioLockSurface() provide the implementation with an explicit hint what area is affected. It can be very useful to know the max. affected area beforehand if getting the bits requires expensive copy operations (e.g., like a roundtrip to the X server or a glReadPixel op). However, the returned pointer *MUST* point to the virtual origin of the surface and not to the beginning of the rectangle. The promise made by BitBlt is to never access data outside the given rectangle (aligned to 4byte boundaries!!) so it is okay to return a pointer to the virtual origin that is actually outside the valid memory area. * The area provided in ioLockSurface() is already clipped (e.g., it will always be inside the source and dest boundingBox) but it is not aligned to word boundaries yet. It is up to the support code to compute accurate alignment if necessary. * Warping always requires the entire source surface to be locked because there is no beforehand knowledge about what area will actually be traversed. " | sourceHandle destHandle l r t b fn | <inline: true> <var: #fn declareC:'sqInt (*fn)(sqInt, sqInt*, sqInt, sqInt, sqInt, sqInt)'> hasSurfaceLock := false. destBits = 0 ifTrue:["Blitting *to* OS surface" lockSurfaceFn = 0 ifTrue:[self loadSurfacePlugin ifFalse:[^nil]]. fn := self cCoerce: lockSurfaceFn to: 'sqInt (*)(sqInt, sqInt*, sqInt, sqInt, sqInt, sqInt)'. destHandle := interpreterProxy fetchInteger: FormBitsIndex ofObject: destForm. (sourceBits = 0 and:[noSource not]) ifTrue:[ sourceHandle := interpreterProxy fetchInteger: FormBitsIndex ofObject: sourceForm. "Handle the special case of equal source and dest handles" (sourceHandle = destHandle) ifTrue:[ "If we have overlapping source/dest we lock the entire area so that there is only one area transmitted" isWarping ifFalse:[ "When warping we always need the entire surface for the source" sourceBits := self cCode:'fn(sourceHandle, &sourcePitch, 0,0, sourceWidth, sourceHeight)'. ] ifTrue:[ "Otherwise use overlapping area" l := sx min: dx. r := (sx max: dx) + bbW. t := sy min: dy. b := (sy max: dy) + bbH. sourceBits := self cCode:'fn(sourceHandle, &sourcePitch, l, t, r-l, b-t)'. ]. destBits := sourceBits. destPitch := sourcePitch. hasSurfaceLock := true. ^destBits ~~ 0 ]. "Fall through - if not equal it'll be handled below" ]. destBits := self cCode:'fn(destHandle, &destPitch, dx, dy, bbW, bbH)'. hasSurfaceLock := true. ]. (sourceBits == 0 and:[noSource not]) ifTrue:["Blitting *from* OS surface" sourceHandle := interpreterProxy fetchInteger: FormBitsIndex ofObject: sourceForm. + interpreterProxy failed ifTrue:[^nil]. "fetch sourceHandle could fail" lockSurfaceFn = 0 ifTrue:[self loadSurfacePlugin ifFalse:[^nil]]. fn := self cCoerce: lockSurfaceFn to: 'sqInt (*)(sqInt, sqInt*, sqInt, sqInt, sqInt, sqInt)'. "Warping requiring the entire surface" isWarping ifTrue:[ sourceBits := self cCode:'fn(sourceHandle, &sourcePitch, 0, 0, sourceWidth, sourceHeight)'. ] ifFalse:[ sourceBits := self cCode:'fn(sourceHandle, &sourcePitch, sx, sy, bbW, bbH)'. ]. hasSurfaceLock := true. ]. ^destBits ~~ 0 and:[sourceBits ~~ 0 or:[noSource]].! Item was changed: ----- Method: StackInterpreter>>returnAs:ThroughCallback:Context: (in category 'callback support') ----- returnAs: returnTypeOop ThroughCallback: vmCallbackContext Context: callbackMethodContext "callbackMethodContext is an activation of invokeCallback:[stack:registers:jmpbuf:]. Its sender is the VM's state prior to the callback. Reestablish that state (via longjmp), and mark callbackMethodContext as dead." <export: true> <var: #vmCallbackContext type: #'VMCallbackContext *'> | calloutMethodContext theFP thePage | <var: #theFP type: #'char *'> <var: #thePage type: #'StackPage *'> ((self isIntegerObject: returnTypeOop) and: [self isLiveContext: callbackMethodContext]) ifFalse: [^false]. calloutMethodContext := self externalInstVar: SenderIndex ofContext: callbackMethodContext. (self isLiveContext: calloutMethodContext) ifFalse: [^false]. "We're about to leave this stack page; must save the current frame's instructionPointer." self push: instructionPointer. self externalWriteBackHeadFramePointers. "Mark callbackMethodContext as dead; the common case is that it is the current frame. We go the extra mile for the debugger." (self isSingleContext: callbackMethodContext) ifTrue: [self markContextAsDead: callbackMethodContext] ifFalse: [theFP := self frameOfMarriedContext: callbackMethodContext. framePointer = theFP "common case" ifTrue: [(self isBaseFrame: theFP) ifTrue: [stackPages freeStackPage: stackPage] ifFalse: "calloutMethodContext is immediately below on the same page. Make it current." [instructionPointer := (self frameCallerSavedIP: framePointer) asUnsignedInteger. stackPointer := framePointer + (self frameStackedReceiverOffset: framePointer) + objectMemory wordSize. framePointer := self frameCallerFP: framePointer. self setMethod: (self frameMethodObject: framePointer). self restoreCStackStateForCallbackContext: vmCallbackContext. "N.B. siglongjmp is defines as _longjmp on non-win32 platforms. This matches the use of _setjmp in ia32abicc.c." self siglong: vmCallbackContext trampoline jmp: (self integerValueOf: returnTypeOop). ^true]] ifFalse: [self externalDivorceFrame: theFP andContext: callbackMethodContext. self markContextAsDead: callbackMethodContext]]. "Make the calloutMethodContext the active frame. The case where calloutMethodContext is immediately below callbackMethodContext on the same page is handled above." (self isStillMarriedContext: calloutMethodContext) ifTrue: [theFP := self frameOfMarriedContext: calloutMethodContext. thePage := stackPages stackPageFor: theFP. "findSPOf:on: points to the word beneath the instructionPointer, but there is no instructionPointer on the top frame of the current page." self assert: thePage ~= stackPage. stackPointer := (self findSPOf: theFP on: thePage) - objectMemory wordSize. framePointer := theFP] ifFalse: [thePage := self makeBaseFrameFor: calloutMethodContext. framePointer := thePage headFP. stackPointer := thePage headSP]. instructionPointer := self popStack. self setMethod: (objectMemory fetchPointer: MethodIndex ofObject: calloutMethodContext). self setStackPageAndLimit: thePage. self restoreCStackStateForCallbackContext: vmCallbackContext. "N.B. siglongjmp is defines as _longjmp on non-win32 platforms. This matches the use of _setjmp in ia32abicc.c." self siglong: vmCallbackContext trampoline jmp: (self integerValueOf: returnTypeOop). "NOTREACHED" ^true! Item was changed: ----- Method: StackToRegisterMappingCogit>>mapDeadDescriptorIfNeeded: (in category 'compile abstract instructions') ----- mapDeadDescriptorIfNeeded: descriptor "insert nops for dead code that is mapped so that bc to mc mapping is not many to one" <var: #descriptor type: #'BytecodeDescriptor *'> self flag: #annotateInstruction . (descriptor isMapped or: [inBlock > 0 and: [descriptor isMappedInBlock]]) ifTrue: [self annotateBytecode: self Nop]. ^ 0!

1 0

VM Maker: VMMaker.oscog-cb.1954.mcz
by commits＠source.squeak.org 29 Sep '16

29 Sep '16

ClementBera uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-cb.1954.mcz ==================== Summary ==================== Name: VMMaker.oscog-cb.1954 Author: cb Time: 29 September 2016, 12:09:23.749488 pm UUID: 34c89fe5-922b-4d01-b2cc-14bd416b3673 Ancestors: VMMaker.oscog-eem.1953 Fixed a bug in the SistaCogit mustBeboolean handling which confused the mcpc to bcpc mapping, forbidding counters to trip correctly. =============== Diff against VMMaker.oscog-eem.1953 =============== Item was changed: ----- Method: SistaCogit>>genJumpIf:to: (in category 'bytecode generator support') ----- genJumpIf: boolean to: targetBytecodePC "The heart of performance counting in Sista. Conditional branches are 6 times less frequent than sends and can provide basic block frequencies (send counters can't). Each conditional has a 32-bit counter split into an upper 16 bits counting executions and a lower half counting untaken executions of the branch. Executing the branch decrements the upper half, tripping if the count goes negative. Not taking the branch decrements the lower half. N.B. We *do not* eliminate dead branches (true ifTrue:/true ifFalse:) so that scanning for send and branch data is simplified and that branch data is correct." <inline: false> | ok counterAddress countTripped retry nextPC nextDescriptor desc | <var: #ok type: #'AbstractInstruction *'> <var: #desc type: #'CogSimStackEntry *'> <var: #retry type: #'AbstractInstruction *'> <var: #countTripped type: #'AbstractInstruction *'> <var: #nextDescriptor type: #'BytecodeDescriptor *'> "In optimized code we don't generate counters to improve performance" (coInterpreter isOptimizedMethod: methodObj) ifTrue: [ ^ super genJumpIf: boolean to: targetBytecodePC ]. "If the branch is reached only for the counter trip trampoline (typically, var1 == var2 ifTrue: falls through to the branch only for the trampoline) we generate a specific path to drastically reduce the number of machine instructions" branchReachedOnlyForCounterTrip ifTrue: [ branchReachedOnlyForCounterTrip := false. ^ self genCounterTripOnlyJumpIf: boolean to: targetBytecodePC ]. "We detect and: / or:, if found, we don't generate the counters to avoid pathological counter slow down" boolean == objectMemory falseObject ifTrue: [ nextPC := bytecodePC + (self generatorAt: byte0) numBytes. nextDescriptor := self generatorAt: (objectMemory fetchByte: nextPC ofObject: methodObj) + bytecodeSetOffset. nextDescriptor generator == #genPushConstantTrueBytecode ifTrue: [ ^ super genJumpIf: boolean to: targetBytecodePC ]. nextDescriptor := self generatorAt: (objectMemory fetchByte: targetBytecodePC ofObject: methodObj) + bytecodeSetOffset. nextDescriptor generator == #genPushConstantFalseBytecode ifTrue: [ ^ super genJumpIf: boolean to: targetBytecodePC ]. ]. extA := 0. "We ignore the noMustBeBoolean flag. It should not be present in methods with counters, and if it is we don't care." "We don't generate counters on branches on true/false, the basicblock usage can be inferred" desc := self ssTop. (desc type == SSConstant and: [desc constant = objectMemory trueObject or: [desc constant = objectMemory falseObject]]) ifTrue: [ ^ super genJumpIf: boolean to: targetBytecodePC ]. self ssFlushTo: simStackPtr - 1. desc popToReg: TempReg. self ssPop: 1. "We need SendNumArgsReg because of the mustBeBooleanTrampoline" self ssAllocateRequiredReg: SendNumArgsReg. retry := self Label. self genExecutionCountLogicInto: [ :cAddress :countTripBranch | counterAddress := cAddress. countTripped := countTripBranch ] counterReg: SendNumArgsReg. counterIndex := counterIndex + 1. "Cunning trick by LPD. If true and false are contiguous subtract the smaller. Correct result is either 0 or the distance between them. If result is not 0 or their distance send mustBeBoolean." self assert: (objectMemory objectAfter: objectMemory falseObject) = objectMemory trueObject. self genSubConstant: boolean R: TempReg. self JumpZero: (self ensureFixupAt: targetBytecodePC - initialPC). self genFallsThroughCountLogicCounterReg: SendNumArgsReg counterAddress: counterAddress. self CmpCq: (boolean == objectMemory falseObject ifTrue: [objectMemory trueObject - objectMemory falseObject] ifFalse: [objectMemory falseObject - objectMemory trueObject]) R: TempReg. ok := self JumpZero: 0. self MoveCq: 0 R: SendNumArgsReg. "if counterReg is 0 this is a mustBeBoolean, not a counter trip." countTripped jmpTarget: (self CallRT: (boolean == objectMemory falseObject ifTrue: [ceSendMustBeBooleanAddFalseTrampoline] ifFalse: [ceSendMustBeBooleanAddTrueTrampoline])). "If we're in an image which hasn't got the Sista code loaded then the ceCounterTripped: trampoline will return directly to machine code, returning the boolean. So the code should jump back to the retry point. The trampoline makes sure that TempReg has been reloaded." + self annotateBytecode: self Label. "For some reason if I write self annotateBytecode: (self Jump: retry) the annotation is not at the correct place." + self Jump: retry. - self annotateBytecode: (self Jump: retry). ok jmpTarget: self Label. ^0!

1 0

[OpenSmalltalk/opensmalltalk-vm] eab7c7: I added extra memory accessors that are used by th...
by GitHub 27 Sep '16

27 Sep '16

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: eab7c70756d3d4308c68723d6e3084ccbbd52a91 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/eab7c70756d3d4308c… Author: Ronie Salgado <roniesalg(a)gmail.com> Date: 2016-09-08 (Thu, 08 Sep 2016) Changed paths: A platforms/Cross/vm/sqLowcodeFFI-Unsupported.h A platforms/Cross/vm/sqLowcodeFFI-i386.h A platforms/Cross/vm/sqLowcodeFFI-x86_64.h A platforms/Cross/vm/sqLowcodeFFI.h M platforms/Cross/vm/sqMemoryAccess.h A specs/lowcode.xml Log Message: ----------- I added extra memory accessors that are used by the Lowcode VM. I added the Lowcode inline FFI callout platform specific glue code that is used by the StackInterpreter. Commit: e0c07d3bab0a8fd47c27b1e129c56498f0d7f60d https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e0c07d3bab0a8fd47c… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2016-09-27 (Tue, 27 Sep 2016) Changed paths: A platforms/Cross/vm/sqLowcodeFFI-Unsupported.h A platforms/Cross/vm/sqLowcodeFFI-i386.h A platforms/Cross/vm/sqLowcodeFFI-x86_64.h A platforms/Cross/vm/sqLowcodeFFI.h M platforms/Cross/vm/sqMemoryAccess.h A specs/lowcode.xml Log Message: ----------- Merge pull request #51 from ronsaldo/Cog VM support changes required by the LowcodeVM Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/873b0c68b817...e0…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev September 2016