Vm-dev January 2020

vm-dev@lists.squeakfoundation.org

35 participants
236 discussions

[OpenSmalltalk/opensmalltalk-vm] 84ccd0: Change any and all sqMakeMemory...Executable... pr...
by Eliot Miranda 31 Jan '20

31 Jan '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 84ccd0aa7a6bc9b3c4182c3810b678fa89d9e834 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/84ccd0aa7a6bc9b3c4… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-01-31 (Fri, 31 Jan 2020) Changed paths: M platforms/Cross/vm/sq.h M platforms/Mac OS/vm/sqMacMemory.c M platforms/iOS/vm/Common/sqMacV2Memory.c M platforms/minheadless/unix/sqPlatformSpecific-Unix.h M platforms/minheadless/unix/sqUnixMemory.c M platforms/minheadless/unix/sqUnixSpurMemory.c M platforms/minheadless/windows/sqPlatformSpecific-Win32.h M platforms/minheadless/windows/sqWin32Alloc.c M platforms/minheadless/windows/sqWin32SpurAlloc.c M platforms/unix/vm/sqUnixMemory.c M platforms/unix/vm/sqUnixSpurMemory.c M platforms/win32/vm/sqWin32Alloc.c M platforms/win32/vm/sqWin32SpurAlloc.c Log Message: ----------- Change any and all sqMakeMemory...Executable... prototypes and implementations to use usqInt for address arguments (sqInt must be used for teh delta arg). IMO we should use usqInt where it makes sense (our APIs rather than OS APIs). I'm not interested in supporting 64-bit oops in 32-bit hosts, or 32-bit oops in 64-bit hosts, so I think it safe to assume that usqInt is equiavlent to usqIntptr_t, & sqInt to sqIntptr_t, and they're shorter. I'm open to persuasion so if I'm wrong please correct me (and the source).

1 0

Build failed: opensmalltalk-vm 1.0.1933
by AppVeyor 31 Jan '20

31 Jan '20

1 0

Still Failing: OpenSmalltalk/opensmalltalk-vm#1934 (Cog - 0876850)
by Travis CI 31 Jan '20

31 Jan '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #1934 Status: Still Failing Duration: 41 mins and 8 secs Commit: 0876850 (Cog) Author: Nicolas Cellier Message: Make Win32 prototype of ioSetCursorARGB Cross-compatible conflicting prototype make compilation fail View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/0f14516f9ad1...08… View the full build log and details: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/644451993?utm_m… -- 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

Build failed: opensmalltalk-vm 1.0.44
by AppVeyor 31 Jan '20

31 Jan '20

1 0

Fix for label duplications in Slang's case expansion
by Guillermo Polito 31 Jan '20

31 Jan '20

Hi all, with Federico, a student from Argentina, we have found a problem in the label generation inside expanded cases in Slang. The problem comes from the fact that expanded cases (using the pragma <expandCase>, typically used for bytecodes), duplicate the entire tree with its inlines too, also duplicating labels inside it, which generates compilation errors due to label redefinition. I’ve written a test for the case: | translation method codeGenerator | method := self class >> #methodWithCases. translation := method asTranslationMethodOfClass: TMethod. codeGenerator := CCodeGeneratorGlobalStructure new. codeGenerator addMethod: ((self class >> #expanded) asTranslationMethodOfClass: TMethod). codeGenerator addMethod: translation. codeGenerator prepareMethods. codeGenerator inlineDispatchesInMethodNamed: #methodWithCases localizingVars: #(). self assert: translation statements first cases first statements last isLabel. self assert: translation statements first cases third statements last isLabel. self deny: translation statements first cases first statements last label equals: translation statements first cases third statements last label. And I’ve made a fix that renames labels on each expanded case, to ensure non shared labels are unique within each case. I’ve put it in vmmaker's inbox. I hope there are no problems regarding timestamps, I’ve been careful about that ^^. Commit + commit message below: Name: VMMaker.oscog-GuillermoPolito.2676 Author: GuillermoPolito Time: 24 January 2020, 4:27:09.847804 pm UUID: 49bcc820-4659-0d00-b258-043c01043dd2 Ancestors: VMMaker.oscog-eem.2675 Fix in slang case statement expansion labels. During expansion in case statements, trees are duplicated and expanded. However, labels inside those trees are duplicated using the same name, producing compilation problems due to label conflicts/redefinition. This fix uses #renameLabelsForInliningInto: when expanding case statements to rewrite labels generating unique labels. Cheers, Guille

3 7

Failed: OpenSmalltalk/opensmalltalk-vm#1933 (Cog - 0f14516)
by Travis CI 31 Jan '20

31 Jan '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #1933 Status: Failed Duration: 36 mins and 55 secs Commit: 0f14516 (Cog) Author: Eliot Miranda Message: And the minheadless builds need to update from sqMakeMemoryExecutableFromTo to sqMakeMemoryExecutableFromToCodeToDataDelta View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/1cbb668e7f45...0f… View the full build log and details: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/644173194?utm_m… -- 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

Build failed: opensmalltalk-vm 1.0.1932
by AppVeyor 31 Jan '20

31 Jan '20

1 0

Build failed: opensmalltalk-vm 1.0.43
by AppVeyor 31 Jan '20

31 Jan '20

1 0

[OpenSmalltalk/opensmalltalk-vm] 0f1451: And the minheadless builds need to update from sqM...
by Eliot Miranda 31 Jan '20

31 Jan '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 0f14516f9ad102125a11b45f0e4a21c98f8272fd https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f14516f9ad102125a… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-01-30 (Thu, 30 Jan 2020) Changed paths: M platforms/minheadless/unix/sqUnixSpurMemory.c M platforms/minheadless/windows/sqWin32SpurAlloc.c Log Message: ----------- And the minheadless builds need to update from sqMakeMemoryExecutableFromTo to sqMakeMemoryExecutableFromToCodeToDataDelta

1 0

Errored: OpenSmalltalk/opensmalltalk-vm#1932 (Cog - 1cbb668)
by Travis CI 31 Jan '20

31 Jan '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #1932 Status: Errored Duration: 22 mins and 57 secs Commit: 1cbb668 (Cog) Author: Eliot Miranda Message: CogVM source as per VMMaker.oscog-eem.2692 ThreadedFFIPlugins: See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/443 FFI support for returning of a packed struct by value in X64 SysV On X64/SysV struct up to 16 byte long can be passed by value into a pair of 8-byte registers. The problem is to know whether these are int (RAX RDX) or float (XMM0 XMM1) registers or eventually a mix of... For each 8-byte, we must know if it contains at least an int (in which case we have to use an int register), or exclusively floating points (a pair of float or a double). Previous algorithm did check first two fields, or last two fields which does not correctly cover all cases... For example int-int-float has last two fields int-float, though it will use RAX XMM0. So we have to know about struct layout... Unfortunately, this information is not included into the compiledSpec. The idea here is to reconstruct the information. See #registerTypeForStructSpecs:OfLength: It's also impossible to cover the exotic alignments like packed structure cases... But if we really want to pass that, this will mean passing the alignment information, a more involved change of #compiledSpec (we need up to 16 bits by field to handle that information since our FFI struct are limited to 65535 bytes anyway). For returning a struct, that's the same problem. We have four possible combinations of int-float registers. Consequently, the idea is to analyze the ffiRetSpec compiledSpec object thru CalloutState (it's the Smalltalk WordArray object, not a pointer to its firstIndexableField) for performing this analysis... Not sure if the best choice. Since we have 4 different SixteenByte types, I have changed value, since it's what will be used to memcpy to allocated ByteArray handle. Checking the size of a struct is not the only condition for returning a struct via registers. Some ABI like X64 SysV also mandates that struct fields be properly aligned. Therefore, we cannot just rely on #returnStructInRegisters:. Rename #returnStructInRegisters: -> #canReturnInRegistersStructOfSize: Perform a more thorough analysis during the setup in #ffiCheckReturn:With:in: The ABI will #encodeStructReturnTypeIn: a new callout state. This structReturnType is telling how the struct should be returned - via registers (and which registers) - or via pointer to memory allocated by caller This structReturnType will be used at time of: - allocating the memory in caller - see #ffiCall:ArgArrayOrNil:NumArgs: - dispatching to the correct FFI prototype - see ThreadedX64SysVFFIPlugin>>#ffiCalloutTo:SpecOnStack:in: - copying back the struct contents to ExternalStructure handle (a ByteArray) - see #ffiReturnStruct:ofType:in: Since structReturnType is encoded, it is not necessarily accessed directly, but rather via new implementation of #returnStructInRegisters: whch now takes the calloutState and knows how to decode its structReturnType. Check for unaligned struct and pass them in MEMORY (alloca'd memory passed thru a pointer). Use a new (branchless) formulation for aligning the byteSize to next multiple of fieldAlignment. Encode registryType of invalid unaligned candidate as 2r110, and pass the struct address returned by the foreign function in $RAX register in place of callout limit when stuct is returned by MEMORY. CoInterpreter: eliminate all but one compiler warning. Cogit/Slang: fix several C compiler warnings re the Cogits. Cogit: DUAL_MAPPED_CODE_ZONE (require -DDUAL_MAPPED_CODE_ZONE=1 to enable) Fix denial of write/execute facility on modern Linuxes by dual mapping the code zone in to a read/execute address range for code execution and a read/write address range for code editing. Maintain codeToDataDelta and provide codeXXXAt:put: to write at address + codeToDataDelta to the offset writable address range. Hence DUAL_MAPPED_CODE_ZONE requires a new executbale permissions applyer that will also do the dual mapping, sqMakeMemoryExecutableFrom:To:CodeToDataDelta:. Provide writableMethodFor: as a convenience for obtaining a writable cogMethod. No longer have the fillInXXXHeaderYYY: methods answer anything since they're given the writable header, not the actual header. Cogit: Refactor indexForSelector:in:at: to indexForSelector:in: in the back end so it can be inlined (via a macro). Slang: emit constant for (M << N) and (M - N) - L for constant integers. Fix in slang case statement expansion labels. During expansion in case statements, trees are duplicated and expanded. View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/4e57f60a0980...1c… View the full build log and details: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/644159560?utm_m… -- 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

← Newer
1
2
3
4
5
6
7
8
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev January 2020