<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Nicolas --<div><br></div><div>Thanks for finding this workaround!</div><div><br></div><div>Given some later point in time, how bad could it bite us back considering extA vs extB? Would one notice this very quickly? What does "<span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">careful recompilation of CompiledMethod at image side" mean here? What can go wrong?</span></div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
<p style='color: #AAAAAA; margin-top: 10px;'>Am 09.03.2022 13:05:56 schrieb commits@source.squeak.org <commits@source.squeak.org>:</p><div style='font-family:Arial,Helvetica,sans-serif'> <br>Nicolas Cellier uploaded a new version of VMMaker to project VM Maker Inbox:<br>http://source.squeak.org/VMMakerInbox/VMMaker.oscog-nice.3174.mcz<br><br>==================== Summary ====================<br><br>Name: VMMaker.oscog-nice.3174<br>Author: nice<br>Time: 9 March 2022, 1:04:51.911686 pm<br>UUID: af4f8704-18fa-564c-ac59-27c6f6364c59<br>Ancestors: VMMaker.oscog-eem.3173<br><br>Workaround : literal characters should have unsigned values<br><br>Currently in SistaV1, characters in range 16r100 16rFFFF are encoded as push literal character (bytecode 233) with signed extended B.<br><br>This lead to negative character values in the range 16r8000 to 16rFFFF.<br><br>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.<br><br>An alternative would be to use extA rather than extB. But it would require a careful recompilation of CompiledMethod at image side.<br><br>Similar fix is required at image side in InstructionStream>>#interpretNext2ByteSistaV1Instruction:for:extA:extB:startPC:<br><br>=============== Diff against VMMaker.oscog-eem.3173 ===============<br><br>Item was changed:<br> ----- Method: SimpleStackBasedCogit>>genExtPushCharacterBytecode (in category 'bytecode generators') -----<br> genExtPushCharacterBytecode<br> "SistaV1: 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B * 256)"<br> | value |<br>+ value := byte1 + ((extB bitAnd: 16rFF) << 8).<br>- value := byte1 + (extB << 8).<br> extB := 0.<br> numExtB := 0.<br> ^self genPushLiteral: (objectMemory characterObjectOf: value)!<br><br>Item was changed:<br> ----- Method: StackInterpreter>>extPushCharacterBytecode (in category 'stack bytecodes') -----<br> extPushCharacterBytecode<br> "SistaV1: * 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B * 256)"<br> | value |<br>+ value := self fetchByte + ((extB bitAnd: 16rFF) << 8).<br>- value := self fetchByte + (extB << 8).<br> self fetchNextBytecode.<br> self internalPush: (objectMemory characterObjectOf: value).<br> numExtB := extB := 0!<br><br></div></blockquote>
</div></body>