<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 this explanation.</div><div><br></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> However, all this might as well be a false problem. How many literal</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> characters > 16rFF do we have in trunk ?</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> Since we had poor support for extended (not to say unicode) fonts until</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> recently, probably not that many ! A $? in source code is not helpful !</span><br></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Yes, the source code in Trunk is fine. I stumbled upon this issue while debugging things around Character, #leadingChar, glyph browsing, and TextConverter. I got used to putting a $ in front of some visible thing in a text field to then send #charCode, #asInteger, or #leadingChar to it. Being able to do-it/inspect-it/print-it in any text field is very convenient. I could have done this via    '...' first    as well. An exception would have been nice, though.</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">For the time being, it makes sense to just signal an error when the user tries to create literal characters between 16r8000 and 16rFFFF.</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">If you happen to know the exact place in the image, would you mind adding this check in Trunk to EncoderForSistaV1? :-)</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Best,</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Marcel</span></span></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;min-width: 500px">

                        <p style="color: #AAAAAA; margin-top: 10px;">Am 09.03.2022 23:16:25 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Hi Marcel, using extA instead of extB need synchronization between

<br>- VM to use extA in SistaV1 interpreter (and jit)

<br>- image side to use extA in compiled code generation (EncoderForSistaV1)

<br>

Being careful is maybe not necessary if we have all source code reachable.

<br>I was thinking of the case when we have to decompile, that would mean

decompile with extB, recompile with extA.

<br>One careful solution would be to

<br>- restrict optimized Character value in range 0-16rFF

<br>- recompile all

<br>- switch to extA in VM and image side

<br>- restore optimized Character value in range 0-16rFFFF

<br>- recompile all

<br>

<br>But mixing old extB VM and new extA image or vice versa would lead to bad

things (loose upper bits of literal character value).

<br>Having a VM supporting both extB + extA would come at an extra cost (maybe

<br>not that high, it could be a simple extB+extA bitAnd: 16rFF)

So I'd better ask for Eliot advice.

<br>The main interest of extA is that it could be extended above 16rFFFF simply

by chaining several extended A (224) bytecodes.

<br>This is not as easy with extB, we have to undo the signed transform taking

numExtB into account...

<br>

<br>Alternatively, we could try to workaround at image side: test the VM at

<br>image startup. Recompiling at startup is too heavy, better operate at a

<br>lower level, that is detect and fix incompatible compiled method (find

<br>which is using extB (225)+pushLiteralChar (233) and replace with

extA(224)+puchLiteralChar or vice versa).

<br>Seems a bit overkill to me, and does not fix the case old image (without

workaround) + new VM.

<br>

<br>However, all this might as well be a false problem. How many literal

characters > 16rFF do we have in trunk ?

<br>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>

<br>

<br>Le mer. 9 mars 2022 à 13:16, Marcel Taeumel <marcel.taeumel@hpi.de> a

<br>écrit :

<br>

<br>>

<br>> Hi Nicolas --

<br>>

> Thanks for finding this workaround!

<br>>

<br>> Given some later point in time, how bad could it bite us back considering

<br>> extA vs extB? Would one notice this very quickly? What does "careful

> recompilation of CompiledMethod at image side" mean here? What can go wrong?

<br>>

<br>> Best,

<br>> Marcel

<br>>

<br>> Am 09.03.2022 13:05:56 schrieb commits@source.squeak.org <

<br>> commits@source.squeak.org>:

<br>>

<br>> Nicolas Cellier uploaded a new version of VMMaker to project VM Maker

<br>> 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>>

> 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

<br>> it as unsigned char. BEWARE: this assumes that a single extB will be used

<br>> rather than multiple consecutive extB. It works by now, because it's

<br>> currently the case that image side only use 1 extB for encoding literal

<br>> 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

<br>> InstructionStream>>#interpretNext2ByteSistaV1Instruction:for:extA:extB:startPC:

<br>>

<br>> =============== Diff against VMMaker.oscog-eem.3173 ===============

<br>>

<br>> Item was changed:

<br>> ----- Method: SimpleStackBasedCogit>>genExtPushCharacterBytecode (in

<br>> category 'bytecode generators') -----

<br>> genExtPushCharacterBytecode

<br>> "SistaV1: 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B *

<br>> 256)"

<br>> | value |

<br>> + value := byte1 + ((extB bitAnd: 16rFF) << 8).

<br>> - value := byte1 + (extB << 8).

<br>> extB := 0.

<br>> numExtB := 0.

> ^self genPushLiteral: (objectMemory characterObjectOf: value)!

<br>>

<br>> Item was changed:

<br>> ----- Method: StackInterpreter>>extPushCharacterBytecode (in category

<br>> 'stack bytecodes') -----

<br>> extPushCharacterBytecode

<br>> "SistaV1: * 233 11101001 iiiiiiii Push Character #iiiiiiii (+ Extend B *

<br>> 256)"

<br>> | value |

<br>> + value := self fetchByte + ((extB bitAnd: 16rFF) << 8).

<br>> - value := self fetchByte + (extB << 8).

<br>> self fetchNextBytecode.

> self internalPush: (objectMemory characterObjectOf: value).

<br>> numExtB := extB := 0!

<br>>

<br>>

<br><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;min-width: 500px"> <div><div id="gmail-m_-3150319572720996039__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0);text-align: left" dir="ltr">

<br>                                        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;min-width: 500px">

<br>                        <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>

<br>                                        </div></div></blockquote></div>

<br></marcel.taeumel@hpi.de></div></blockquote></div>