<div dir="ltr"><div>Hi Marcel, using extA instead of extB need synchronization between</div><div>- VM to use extA in SistaV1 interpreter (and jit)<br></div><div>- image side to use extA in compiled code generation (EncoderForSistaV1)</div><div><br></div><div>Being careful is maybe not necessary if we have all source code reachable.</div><div>I was thinking of the case when we have to decompile, that would mean decompile with extB, recompile with extA.</div><div>One careful solution would be to</div><div>- restrict optimized Character value in range 0-16rFF</div><div>- recompile all</div><div>- switch to extA in VM and image side<br><div>- restore optimized Character value in range 0-16rFFFF</div><div>- recompile all</div><div><br></div><div>But mixing old extB VM and new extA image or vice versa would lead to bad things (loose upper bits of literal character value).</div><div>Having a VM supporting both extB + extA would come at an extra cost (maybe not that high, it could be a simple extB+extA bitAnd: 16rFF)<div>So I'd better ask for Eliot advice.<div>The main interest of extA is that it could be extended above 16rFFFF simply by chaining several extended A (224) bytecodes.</div>This is not as easy with extB, we have to undo the signed transform taking numExtB into account...</div><div><br></div></div><div>Alternatively, we could try to workaround at image side: test the VM at image startup. Recompiling at startup is too heavy, better operate at a lower level, that is detect and fix incompatible compiled method (find which is using extB (225)+pushLiteralChar (233) and replace with extA(224)+puchLiteralChar or vice versa).</div><div>Seems a bit overkill to me, and does not fix the case old image (without workaround) + new VM.</div><div><br></div><div>However, all this might as well be a false problem. How many literal characters > 16rFF do we have in trunk ?</div><div>Since we had poor support for extended (not to say unicode) fonts until recently, probably not that many ! A $? in source code is not helpful !<br> </div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 13:16, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><div id="gmail-m_-3150319572720996039__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);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></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px">
<p style="color:rgb(170,170,170);margin-top:10px">Am 09.03.2022 13:05:56 schrieb <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> <br>Nicolas Cellier uploaded a new version of VMMaker to project VM Maker Inbox:<br><a href="http://source.squeak.org/VMMakerInbox/VMMaker.oscog-nice.3174.mcz" target="_blank">http://source.squeak.org/VMMakerInbox/VMMaker.oscog-nice.3174.mcz</a><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></div></blockquote></div>