Vm-dev March 2022

vm-dev@lists.squeakfoundation.org

14 participants
35 discussions

Start a nNew thread

[OpenSmalltalk/opensmalltalk-vm]
by Tobias Pape 16 Mar '22

16 Mar '22

Branch: refs/heads/krono/freebsd-fixes Home: https://github.com/OpenSmalltalk/opensmalltalk-vm

1 0

[OpenSmalltalk/opensmalltalk-vm]
by Tobias Pape 16 Mar '22

16 Mar '22

Branch: refs/heads/krono/openbsd Home: https://github.com/OpenSmalltalk/opensmalltalk-vm

1 0

[OpenSmalltalk/opensmalltalk-vm]
by Tobias Pape 16 Mar '22

16 Mar '22

Branch: refs/heads/c99 Home: https://github.com/OpenSmalltalk/opensmalltalk-vm

1 0

[OpenSmalltalk/opensmalltalk-vm] Incorrect literal Character encoding/decoding in SistaV1 bytecode set (Issue #618)
by Nicolas Cellier 11 Mar '22

11 Mar '22

As reported by Marcel on Squeak-dev, this snippet: Compiler evaluate: (String with: $$ with: (Character value: 16r8000)). will return a Character with a negative value (-32768). This is because character literal in the range 16r100-16rFFFF are encoded with an extended B bytecode, and the extended B is interpreted as signed value. I suggested - a workaround : using `(extB bitAnd: 16rFF) << 8` to reconstruct an unsigned Character value - a fix: using extA instead of extB so as to have it interpreted unsigned See https://source.squeak.org/VMMakerInbox/VMMaker.oscog-nice.3174.diff for the former solution. The later solution require more changes and a careful recompilation of CompiledMethods at image side. -- Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/618 You are receiving this because you are subscribed to this thread. Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/618(a)github.com>

3 6

[OpenSmalltalk/opensmalltalk-vm] d5835e: CogVM source as per VMMaker.oscog-eem.3174
by Eliot Miranda 10 Mar '22

10 Mar '22

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: d5835e5ea2d427647e6b6bef7d11d6eba4fe7ea8 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d5835e5ea2d427647e… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2022-03-10 (Thu, 10 Mar 2022) Changed paths: M src/spur32.cog.lowcode/cogit.h M src/spur32.cog.lowcode/cogitARMv5.c M src/spur32.cog.lowcode/cogitIA32.c M src/spur32.cog.lowcode/cointerp.c M src/spur32.cog.lowcode/cointerp.h M src/spur32.cog.lowcode/gcc3x-cointerp.c M src/spur32.cog/cogit.h M src/spur32.cog/cogitARMv5.c M src/spur32.cog/cogitIA32.c M src/spur32.cog/cointerp.c M src/spur32.cog/cointerp.h M src/spur32.cog/cointerpmt.c M src/spur32.cog/cointerpmt.h M src/spur32.cog/gcc3x-cointerp.c M src/spur32.cog/gcc3x-cointerpmt.c M src/spur32.sista/cogit.h M src/spur32.sista/cogitARMv5.c M src/spur32.sista/cogitIA32.c M src/spur32.sista/cointerp.c M src/spur32.sista/cointerp.h M src/spur32.sista/gcc3x-cointerp.c M src/spur32.stack.lowcode/gcc3x-interp.c M src/spur32.stack.lowcode/interp.c M src/spur32.stack/gcc3x-interp.c M src/spur32.stack/interp.c M src/spur32.stack/validImage.c M src/spur64.cog.lowcode/cogit.h M src/spur64.cog.lowcode/cogitARMv8.c M src/spur64.cog.lowcode/cogitX64SysV.c M src/spur64.cog.lowcode/cogitX64WIN64.c M src/spur64.cog.lowcode/cointerp.c M src/spur64.cog.lowcode/cointerp.h M src/spur64.cog.lowcode/gcc3x-cointerp.c M src/spur64.cog/cogit.h M src/spur64.cog/cogitARMv8.c M src/spur64.cog/cogitX64SysV.c M src/spur64.cog/cogitX64WIN64.c M src/spur64.cog/cointerp.c M src/spur64.cog/cointerp.h M src/spur64.cog/cointerpmt.c M src/spur64.cog/cointerpmt.h M src/spur64.cog/gcc3x-cointerp.c M src/spur64.cog/gcc3x-cointerpmt.c M src/spur64.sista/cogit.h M src/spur64.sista/cogitARMv8.c M src/spur64.sista/cogitX64SysV.c M src/spur64.sista/cogitX64WIN64.c M src/spur64.sista/cointerp.c M src/spur64.sista/cointerp.h M src/spur64.sista/gcc3x-cointerp.c M src/spur64.stack.lowcode/gcc3x-interp.c M src/spur64.stack.lowcode/interp.c M src/spur64.stack/gcc3x-interp.c M src/spur64.stack/interp.c M src/spur64.stack/validImage.c M src/v3.cog/cogit.h M src/v3.cog/cogitARMv5.c M src/v3.cog/cogitIA32.c M src/v3.cog/cointerp.c M src/v3.cog/cointerp.h M src/v3.cog/gcc3x-cointerp.c M src/v3.stack/gcc3x-interp.c M src/v3.stack/interp.c Log Message: ----------- CogVM source as per VMMaker.oscog-eem.3174 Fix https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/618 by redefining the extended Push Character bytecode 233. Since character values are unsigned it makes more sense to redefine the bytecode to take extA, the unsigned extension. While this is potentially dangerous for older images I'm (eem) taking this approach because - AFAICT the exctended bytecode isn't in use in typical code - those who are affected (primarily Marcel working on extended character support) can upgrade to a fixed VM - Nicolas has deployed a patch to the compiler that avoids using the extension, and this can be elaborated to check if the VM is new enough before using extA. - longer term using the unsigned extension is the more correct fix. Commit: 6d38f13347be1031168b8b02e8ca52dc1b74be1c https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/6d38f13347be103116… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2022-03-10 (Thu, 10 Mar 2022) Changed paths: M src/spur32.stack/validImage.c M src/spur64.stack/validImage.c Log Message: ----------- Hmmm, somehow validImage.c was generated with CR line terminators. Hack fix it for now. Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/b558efdd677d...6d…

1 0

VM Maker: VMMaker.oscog-eem.3174.mcz
by commits＠source.squeak.org 10 Mar '22

10 Mar '22

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.3174.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.3174 Author: eem Time: 10 March 2022, 11:45:52.513666 am UUID: 2edcc3c8-ba87-4012-b4f4-ea60094be91f Ancestors: VMMaker.oscog-eem.3173 Fix https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/618 by redefining the extended Push Character bytecode 233. Since character values are unsigned it makes more sense to redefine the bytecode to take extA, the unsigned extension. While this is potentially dangerous for older images I'm taking this approach because - AFAICT the exctended bytecode isn't in use in typical code - those who are affected (primarily Marcel working on extended character support) can upgrade to a fixed VM - Nicolas has deployed a patch to the compiler that avoids using the extension, and this can be elaborated to check if the VM is new enough before using extA. - longer term using the unsigned extension is the more correct fix. =============== Diff against VMMaker.oscog-eem.3173 =============== Item was changed: ----- Method: SimpleStackBasedCogit>>genExtPushCharacterBytecode (in category 'bytecode generators') ----- genExtPushCharacterBytecode + "SistaV1: 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend A * 256)" - "SistaV1: 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B * 256)" | value | + value := byte1 + (extA << 8). + extA := 0. - value := byte1 + (extB << 8). - extB := 0. - numExtB := 0. ^self genPushLiteral: (objectMemory characterObjectOf: value)! Item was changed: ----- Method: StackInterpreter>>extPushCharacterBytecode (in category 'stack bytecodes') ----- extPushCharacterBytecode + "SistaV1: * 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend A * 256)" - "SistaV1: * 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B * 256)" | value | + value := self fetchByte + (extA << 8). - value := self fetchByte + (extB << 8). self fetchNextBytecode. self internalPush: (objectMemory characterObjectOf: value). + extA := 0! - numExtB := extB := 0!

1 0

VM Maker: VMMaker.oscog-eem.3174.mcz
by commits＠source.squeak.org 10 Mar '22

10 Mar '22

1 0

Sign-bit bug in character literals > 16r7FFF ... related to SistaV1?
by Marcel Taeumel 10 Mar '22

10 Mar '22

Hi Eliot, hi all -- I think we have an sign-bit bug for character literals with code points > 16r7FFF. Steps to reproduce: 1. Print it: "Character value: 16r8000" 2. Inspect the result by evaluating the character literal or send #asInteger to it. It will most likely not render in a standard Squeak and show up like "$? asInteger". In a 32-bit VM, I will get the (positive) integer value 16r3FFF8000. In a 64-bit VM, I will get the (negative) integer value '-16r8000'. Somehow, starting at bit 0, the bits 16 to 29 flip from 0 to 1. In 64-bit, this means a negative number. Not sure about bits 30 and 31 here. Is there a bug in the upper tag bits of immediate characters? Is this related to the 2-byte or 3-byte byte codes in SistaV1? Works fine up to 16r7FFF. (This is unrelated to #leadingChar. Mine was 0 in this experiment.) VM: 202112201228 (VMMaker.oscog-eem.3116) Best, Marcel

5 14

VM Maker Inbox: VMMaker.oscog-nice.3174.mcz
by commits＠source.squeak.org 10 Mar '22

10 Mar '22

Nicolas Cellier uploaded a new version of VMMaker to project VM Maker Inbox: http://source.squeak.org/VMMakerInbox/VMMaker.oscog-nice.3174.mcz ==================== Summary ==================== Name: VMMaker.oscog-nice.3174 Author: nice Time: 9 March 2022, 1:04:51.911686 pm UUID: af4f8704-18fa-564c-ac59-27c6f6364c59 Ancestors: VMMaker.oscog-eem.3173 Workaround : literal characters should have unsigned values Currently in SistaV1, characters in range 16r100 16rFFFF are encoded as push literal character (bytecode 233) with signed extended B. This lead to negative character values in the range 16r8000 to 16rFFFF. The workaround consist in bit-oring extB with 16rFF so as to re-interpret it as unsigned char. BEWARE: this assumes that a single extB will be used rather than multiple consecutive extB. It works by now, because it's currently the case that image side only use 1 extB for encoding literal character - see EncoderForSistaV1>>#genPushCharacter: - above 16rFFFF, a literal index is consumed. An alternative would be to use extA rather than extB. But it would require a careful recompilation of CompiledMethod at image side. Similar fix is required at image side in InstructionStream>>#interpretNext2ByteSistaV1Instruction:for:extA:extB:startPC: =============== Diff against VMMaker.oscog-eem.3173 =============== Item was changed: ----- Method: SimpleStackBasedCogit>>genExtPushCharacterBytecode (in category 'bytecode generators') ----- genExtPushCharacterBytecode "SistaV1: 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B * 256)" | value | + value := byte1 + ((extB bitAnd: 16rFF) << 8). - value := byte1 + (extB << 8). extB := 0. numExtB := 0. ^self genPushLiteral: (objectMemory characterObjectOf: value)! Item was changed: ----- Method: StackInterpreter>>extPushCharacterBytecode (in category 'stack bytecodes') ----- extPushCharacterBytecode "SistaV1: * 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B * 256)" | value | + value := self fetchByte + ((extB bitAnd: 16rFF) << 8). - value := self fetchByte + (extB << 8). self fetchNextBytecode. self internalPush: (objectMemory characterObjectOf: value). numExtB := extB := 0!

3 4

[OpenSmalltalk/opensmalltalk-vm] Armv8 crash in MVC (Issue #617)
by edoneel 10 Mar '22

10 Mar '22

Hi, ArmV8 crashes when you do the following: 1. Start Squeak. 2. Open a MVC Project 3. in the MVC project open a Workspace 4. Type something, and then enough returns to cause the something to scroll of the screen and the scroll bar to flop out. 5. Scroll back --> segfault. The patch that fixes this is attached. The patch is to take the slow path in fastPathBottomToTop in platforms/Cross/plugins/BitBltPlugin/BitBltGeneric.c This only shows up when you use the optimized flag. Crashes on: gcc version 10.2.1 20210110 (Debian 10.2.1-6) gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) cheers bruce [PatchBitBltGeneric.patch.txt](https://github.com/OpenSmalltalk/opensmalltal… -- Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/617 You are receiving this because you are subscribed to this thread. Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/617(a)github.com>

5 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev March 2022