<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Nicolas --<div class="mb_sig"></div>
                                        <div><br></div><div>Thank you for the advice. Found and fixed the regression</div><div>via <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">VMMaker.oscog-mt.3181.</span></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;font-size: 13px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">It's just that we don't have (or don't run ?) enough tests to</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> notice the </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">regression.</span></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;font-size: 13px">I found this regression by running the FFI tests in a 32-bit </span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">build, which is not possible on a recent macOS. I will now</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">regenerate and push the SqueakFFIPrims sources and</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">update the "long long" tests in a way that they show this</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">kind of problem more quickly in the future.</span></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;font-size: 13px">Maybe I should also test 32-bit builds here:</span></div><div><a href="https://github.com/marceltaeumel/squeak-ffi"><span style="font-size: 10pt;font-family: Arial, Helvetica, sans-serif">https://github.com/marceltaeumel/squeak-ffi</span></a><br></div><div><br></div><div>There still seems to be an issue with FFI on macOS.</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;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></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 12.04.2022 22:40:01 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Hi Marcel,
<br>Because there will still be problems passing 64bits (Large) integers to
<br>FFI, such a partial patch has not enough value.
<br>If we pass a 64 bits value, but only use the 32 low bits, the patch rather
<br>tends to obscure things.
<br>I'm pretty sure that passing a LargeInteger to FFI with 64 bit
<br>(signed/unsigned) int type did work back in 2016, so it's not a new
<br>feature, just a regression.
<br>For example we had specific #ffiPushUnsignedLongLongOop:
<br>#ffiPushSignedLongLongOop: at that time. So we would not necessarily go
<br>through the generic coercion #ffiIntegerValueOf:.
<br>Eliot did refactor since, probably so as to support many other
<br>architectures - which is a good thing.
<br>It's just that we don't have (or don't run ?) enough tests to notice the
<br>regression.
<br>
<br>The fix would be to resort to some kind of #ffiPushUnsignedLongLongOop:
<br>#ffiPushSignedLongLongOop etc...
<br>All the coercion methods could resort to generic #ffiIntegerValueOf:, but
<br>the 2 above on 32 bits arch.
<br>The C compiler will probably easily factor out the #ffiIntegerValueOf:
<br>common to each case branch on 64 bits arch, we don't have to bother for
<br>handcrafted optimization.
<br>I ain't got much time to push it further, but that's not that hard if
<br>someone want to try it out.
<br>
<br>
<br>Le mar. 12 avr. 2022 à 15:27, Marcel Taeumel <marcel.taeumel@hpi.de> a
<br>écrit :
<br>
<br>>
<br>> Hi Nicolas --
<br>>
<br>> Would you mind looking at VMMaker.oscog-mt.3180 in VMMakerInbox?
<br>>
<br>> Do you think this is a good thing to have for the OSVM release? If so, I
<br>> will fix the long-long tests to document this.
<br>>
<br>> Best,
<br>> Marcel
<br>>
<br>> Am 12.04.2022 10:55:33 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:
<br>> Hi Nicolas --
<br>>
<br>> Thanks for the tip. I will have a look.
<br>>
<br>> Do you know whether Squeak FFI 32-bit does (or should) support "long long"
<br>> (or "int64_t") for Large(Positive|Negative)Integer outside the range of
<br>> int32_t?
<br>>
<br>> On 32-bit Squeak, we need both SmallInteger and Large(Positive|Negative)Integer
<br>> to cover int32_t. Not so on 64-bit Squeak. So, I am not sure whether there
<br>> is actually support for int64_t on 32-bit Squeak in this regard...
<br>>
<br>> So, am I looking for a bug or would this rather be a new feature? :-)
<br>>
<br>> Best,
<br>> Marcel
<br>>
<br>> Am 11.04.2022 21:31:58 schrieb Nicolas Cellier <
<br>> nicolas.cellier.aka.nice@gmail.com>:
<br>> Hi Marcel,
<br>> Sounds like 32bits -1 missing a sign extension when converted to 64bits...
<br>> At least, the result is correctly 64bits for sure.
<br>>
<br>> Le lun. 11 avr. 2022 à 18:42, Marcel Taeumel a
<br>> écrit :
<br>>
<br>> >
<br>> > Hi all --
<br>> >
<br>> > This is not working in 32-bit on Windows:
<br>> >
<br>> > FFITestLibrary ffiTest8LongLongSum: -1 with: -1 with: -1 with: -1 with:
<br>> -1
<br>> > with: -1 with: -1 with: -1.
<br>> >
<br>> > It answers " 34359738360 " instead of " - 8 ". It's working fine in a
<br>> > 64-bit build. The debugging output in this test functions says:
<br>> >
<br>> > 8 long longs came in as
<br>> > i1 = 4294967295 (ffffffff)
<br>> > i2 = 4294967295 (ffffffff)
<br>> > i3 = 4294967295 (ffffffff)
<br>> > i4 = 4294967295 (ffffffff)
<br>> > i5 = 4294967295 (ffffffff)
<br>> > i6 = 4294967295 (ffffffff)
<br>> > i7 = 4294967295 (ffffffff)
<br>> > i8 = 4294967295 (ffffffff)
<br>> >
<br>> > ... this is clearly wrong. Or is it? On 64-bit, the same function says:
<br>> >
<br>> > 8 long longs came in as
<br>> > i1 = -1 (ffffffffffffffff)
<br>> > i2 = -1 (ffffffffffffffff)
<br>> > i3 = -1 (ffffffffffffffff)
<br>> > i4 = -1 (ffffffffffffffff)
<br>> > i5 = -1 (ffffffffffffffff)
<br>> > i6 = -1 (ffffffffffffffff)
<br>> > i7 = -1 (ffffffffffffffff)
<br>> > i8 = -1 (ffffffffffffffff)
<br>> >
<br>> > Both are formatted via " %lld (%llx) " I am missing something here...
<br>> did
<br>> > we change the representation of negative integers in Squeak and forgot
<br>> to
<br>> > update something along ThreadedFFIPlugin >> #ffiIntegerValueOf:? :-/
<br>> >
<br>> > Best,
<br>> > Marcel
<br>> >
<br>> > ***
<br>> >
<br>> > EXPORT(long long) ffiTest8LongLongSum(long long c1, long long c2, long
<br>> > long c3, long long c4, long long c5, long long c6, long long c7, long
<br>> long
<br>> > c8)
<br>> > {
<br>> > printf("8 long longs came in as\ni1 = %lld (%llx)\ni2 = %lld (%llx)\ni3
<br>> =
<br>> > %lld (%llx)\ni4 = %lld (%llx)\ni5 = %lld (%llx)\ni6 = %lld (%llx)\ni7 =
<br>> > %lld (%llx)\ni8 = %lld (%llx)\n", c1, c1, c2, c2, c3, c3, c4, c4, c5,
<br>> c5,
<br>> > c6, c6, c7, c7, c8, c8);
<br>> > return c1 + c2 + c3 + c4 + c5 + c6 + c7 + c8;
<br>> > }
<br>> >
<br>> Hi Marcel,
<br>> Sounds like 32bits -1 missing a sign extension when converted to 64bits...
<br>> At least, the result is correctly 64bits for sure.
<br>>
<br>> Le lun. 11 avr. 2022 à 18:42, Marcel Taeumel <marcel.taeumel@hpi.de> a
<br>> écrit :
<br>>
<br>>>
<br>>> Hi all --
<br>>>
<br>>> This is not working in 32-bit on Windows:
<br>>>
<br>>> FFITestLibrary ffiTest8LongLongSum: -1 with: -1 with: -1 with: -1 with:
<br>>> -1 with: -1 with: -1 with: -1.
<br>>>
<br>>> It answers " 34359738360 " instead of " - 8 ". It's working fine in a
<br>>> 64-bit build. The debugging output in this test functions says:
<br>>>
<br>>> 8 long longs came in as
<br>>> i1 = 4294967295 (ffffffff)
<br>>> i2 = 4294967295 (ffffffff)
<br>>> i3 = 4294967295 (ffffffff)
<br>>> i4 = 4294967295 (ffffffff)
<br>>> i5 = 4294967295 (ffffffff)
<br>>> i6 = 4294967295 (ffffffff)
<br>>> i7 = 4294967295 (ffffffff)
<br>>> i8 = 4294967295 (ffffffff)
<br>>>
<br>>> ... this is clearly wrong. Or is it? On 64-bit, the same function says:
<br>>>
<br>>> 8 long longs came in as
<br>>> i1 = -1 (ffffffffffffffff)
<br>>> i2 = -1 (ffffffffffffffff)
<br>>> i3 = -1 (ffffffffffffffff)
<br>>> i4 = -1 (ffffffffffffffff)
<br>>> i5 = -1 (ffffffffffffffff)
<br>>> i6 = -1 (ffffffffffffffff)
<br>>> i7 = -1 (ffffffffffffffff)
<br>>> i8 = -1 (ffffffffffffffff)
<br>>>
<br>>> Both are formatted via " %lld (%llx) " I am missing something here... did
<br>>> we change the representation of negative integers in Squeak and forgot to
<br>>> update something along ThreadedFFIPlugin >> #ffiIntegerValueOf:? :-/
<br>>>
<br>>> Best,
<br>>> Marcel
<br>>>
<br>>> ***
<br>>>
<br>>> EXPORT(long long) ffiTest8LongLongSum(long long c1, long long c2, long
<br>>> long c3, long long c4, long long c5, long long c6, long long c7, long long
<br>>> c8)
<br>>> {
<br>>> printf("8 long longs came in as\ni1 = %lld (%llx)\ni2 = %lld (%llx)\ni3 =
<br>>> %lld (%llx)\ni4 = %lld (%llx)\ni5 = %lld (%llx)\ni6 = %lld (%llx)\ni7 =
<br>>> %lld (%llx)\ni8 = %lld (%llx)\n", c1, c1, c2, c2, c3, c3, c4, c4, c5, c5,
<br>>> c6, c6, c7, c7, c8, c8);
<br>>> return c1 + c2 + c3 + c4 + c5 + c6 + c7 + c8;
<br>>> }
<br>>>
<br>>
<br>>
<br><div dir="ltr"><div>Hi Marcel,</div><div>Because there will still be problems passing 64bits (Large) integers to FFI, such a partial patch has not enough value.</div><div>If we pass a 64 bits value, but only use the 32 low bits, the patch rather tends to obscure things.<br> </div><div>I'm pretty sure that passing a LargeInteger to FFI with 64 bit (signed/unsigned) int type did work back in 2016, so it's not a new feature, just a regression.</div><div>For example we had specific #ffiPushUnsignedLongLongOop: #ffiPushSignedLongLongOop: at that time. So we would not necessarily go through the generic coercion #ffiIntegerValueOf:.</div><div>Eliot did refactor since, probably so as to support many other architectures - which is a good thing.</div><div>It's just that we don't have (or don't run ?) enough tests to notice the regression.</div><div><br></div><div>The fix would be to resort to some kind of #ffiPushUnsignedLongLongOop: #ffiPushSignedLongLongOop etc...<br></div><div>All the coercion methods could resort to generic #ffiIntegerValueOf:, but the 2 above on 32 bits arch.</div><div>The C compiler will probably easily factor out the #ffiIntegerValueOf: common to each case branch on 64 bits arch, we don't have to bother for handcrafted optimization.<br></div><div>I ain't got much time to push it further, but that's not that hard if someone want to try it out.<br> </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 12 avr. 2022 à 15:27, 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 id="gmail-m_-5057219239377985466__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>Would you mind looking at VMMaker.oscog-mt.3180 in VMMakerInbox? </div><div><br></div><div>Do you think this is a good thing to have for the OSVM release? If so, I will fix the long-long tests to document this.</div><div><br></div><div>Best,</div><div>Marcel</div><div></div>
<br>                                        <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 12.04.2022 10:55:33 schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="gmail-m_-5057219239377985466__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 the tip. I will have a look.</div><div><br></div><div>Do you know whether Squeak FFI 32-bit does (or should) support "long long" (or "int64_t") for Large(Positive|Negative)Integer outside the range of int32_t?</div><div><br></div><div>On 32-bit Squeak, we need both SmallInteger and <span style="font-size: 10pt">Large(Positive|Negative)Integer to cover int32_t. Not so on 64-bit Squeak. So, I am not sure whether there is actually support for int64_t on 32-bit Squeak in this regard...</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">So, am I looking for a bug or would this rather be a new feature? :-)</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Best,</span></div><div><span style="font-size: 10pt">Marcel</span></div><div></div>
<br>                                        <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 11.04.2022 21:31:58 schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Hi Marcel,
<br><br>Sounds like 32bits -1 missing a sign extension when converted to 64bits...
<br><br>At least, the result is correctly 64bits for sure.
<br><br>
<br><br>Le lun. 11 avr. 2022 à 18:42, Marcel Taeumel <u></u> a
<br><br>écrit :
<br><br>
<br><br>>
<br><br>> Hi all --
<br><br>>
<br><br>> This is not working in 32-bit on Windows:
<br><br>>
<br><br>> FFITestLibrary ffiTest8LongLongSum: -1 with: -1 with: -1 with: -1 with: -1
<br><br>> with: -1 with: -1 with: -1.
<br><br>>
<br><br>> It answers " 34359738360 " instead of " - 8 ". It's working fine in a
<br><br>> 64-bit build. The debugging output in this test functions says:
<br><br>>
<br><br>> 8 long longs came in as
<br><br>> i1 = 4294967295 (ffffffff)
<br><br>> i2 = 4294967295 (ffffffff)
<br><br>> i3 = 4294967295 (ffffffff)
<br><br>> i4 = 4294967295 (ffffffff)
<br><br>> i5 = 4294967295 (ffffffff)
<br><br>> i6 = 4294967295 (ffffffff)
<br><br>> i7 = 4294967295 (ffffffff)
<br><br>> i8 = 4294967295 (ffffffff)
<br><br>>
<br><br>> ... this is clearly wrong. Or is it? On 64-bit, the same function says:
<br><br>>
<br><br>> 8 long longs came in as
<br><br>> i1 = -1 (ffffffffffffffff)
<br><br>> i2 = -1 (ffffffffffffffff)
<br><br>> i3 = -1 (ffffffffffffffff)
<br><br>> i4 = -1 (ffffffffffffffff)
<br><br>> i5 = -1 (ffffffffffffffff)
<br><br>> i6 = -1 (ffffffffffffffff)
<br><br>> i7 = -1 (ffffffffffffffff)
<br><br>> i8 = -1 (ffffffffffffffff)
<br><br>>
<br><br>> Both are formatted via " %lld (%llx) " I am missing something here... did
<br><br>> we change the representation of negative integers in Squeak and forgot to
<br><br>> update something along ThreadedFFIPlugin >> #ffiIntegerValueOf:? :-/
<br><br>>
<br><br>> Best,
<br><br>> Marcel
<br><br>>
<br><br>> ***
<br><br>>
<br><br>> EXPORT(long long) ffiTest8LongLongSum(long long c1, long long c2, long
<br><br>> long c3, long long c4, long long c5, long long c6, long long c7, long long
<br><br>> c8)
<br><br>> {
<br><br>> printf("8 long longs came in as\ni1 = %lld (%llx)\ni2 = %lld (%llx)\ni3 =
<br><br>> %lld (%llx)\ni4 = %lld (%llx)\ni5 = %lld (%llx)\ni6 = %lld (%llx)\ni7 =
<br><br>> %lld (%llx)\ni8 = %lld (%llx)\n", c1, c1, c2, c2, c3, c3, c4, c4, c5, c5,
<br><br>> c6, c6, c7, c7, c8, c8);
<br><br>> return c1 + c2 + c3 + c4 + c5 + c6 + c7 + c8;
<br><br>> }
<br><br>>
<br><br><div dir="auto">Hi Marcel,<div dir="auto">Sounds like 32bits -1 missing a sign extension when converted to 64bits...</div><div dir="auto">At least, the result is correctly 64bits for sure.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 11 avr. 2022 à 18:42, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" rel="noreferrer noreferrer" target="_blank">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 id="gmail-m_-5057219239377985466m_1045273152890182240m_5944435337651575203m_-5630769014190549904__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: rgb(0,0,0);text-align: left" dir="ltr">Hi all --<div></div><div><br></div><div>This is not working in 32-bit on Windows:</div><div><br></div><div><span style="font-size: 13.3333px">FFITestLibrary ffiTest8LongLongSum: -1 with: -1 with: -1 with: -1 with: -1 with: -1 with: -1 with: -1.</span><br></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">It answers " 34359738360 " instead of " - 8 ". It's working fine in a 64-bit build. The debugging output in this test functions says:</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><div><span style="font-size: 13.3333px">8 long longs came in as</span></div><div><span style="font-size: 13.3333px">i1 = 4294967295 (ffffffff)</span></div><div><span style="font-size: 13.3333px">i2 = 4294967295 (ffffffff)</span></div><div><span style="font-size: 13.3333px">i3 = 4294967295 (ffffffff)</span></div><div><span style="font-size: 13.3333px">i4 = 4294967295 (ffffffff)</span></div><div><span style="font-size: 13.3333px">i5 = 4294967295 (ffffffff)</span></div><div><span style="font-size: 13.3333px">i6 = 4294967295 (ffffffff)</span></div><div><span style="font-size: 13.3333px">i7 = 4294967295 (ffffffff)</span></div><div><span style="font-size: 13.3333px">i8 = 4294967295 (ffffffff)</span></div></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">... this is clearly wrong. Or is it? On 64-bit, the same function says:</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><div style="font-size: 13.3333px">8 long longs came in as</div><div style="font-size: 13.3333px">i1 = -1 (ffffffffffffffff)</div><div style="font-size: 13.3333px">i2 = -1 (ffffffffffffffff)</div><div style="font-size: 13.3333px">i3 = -1 (ffffffffffffffff)</div><div style="font-size: 13.3333px">i4 = -1 (ffffffffffffffff)</div><div style="font-size: 13.3333px">i5 = -1 (ffffffffffffffff)</div><div style="font-size: 13.3333px">i6 = -1 (ffffffffffffffff)</div><div style="font-size: 13.3333px">i7 = -1 (ffffffffffffffff)</div><div style="font-size: 13.3333px">i8 = -1 (ffffffffffffffff)</div><div style="font-size: 13.3333px"><br></div><div style="font-size: 13.3333px">Both are formatted via " %lld (%llx) " I am missing something here... did we change the representation of negative integers in Squeak and forgot to update something along ThreadedFFIPlugin >> #ffiIntegerValueOf:? :-/</div><div style="font-size: 13.3333px"><br></div><div style="font-size: 13.3333px">Best,<br>Marcel</div><div style="font-size: 13.3333px"><br></div><div style="font-size: 13.3333px">***</div><div style="font-size: 13.3333px"><br></div><div><div><span style="font-size: 13.3333px">EXPORT(long long) ffiTest8LongLongSum(long long c1, long long c2, long long c3, long long c4, long long c5, long long c6, long long c7, long long c8)</span></div><div><span style="font-size: 13.3333px">{</span></div><div><span style="font-size: 13.3333px"><span style="white-space:pre-wrap">    </span>printf("8 long longs came in as\ni1 = %lld (%llx)\ni2 = %lld (%llx)\ni3 = %lld (%llx)\ni4 = %lld (%llx)\ni5 = %lld (%llx)\ni6 = %lld (%llx)\ni7 = %lld (%llx)\ni8 = %lld (%llx)\n", c1, c1, c2, c2, c3, c3, c4, c4, c5, c5, c6, c6, c7, c7, c8, c8);</span></div><div><span style="font-size: 13.3333px"><span style="white-space:pre-wrap">   </span>return c1 + c2 + c3 + c4 + c5 + c6 + c7 + c8;</span></div><div><span style="font-size: 13.3333px">}</span></div></div></div></div></blockquote></div>
<br><br><u></u></div></blockquote></div></div></blockquote></div></blockquote></div>
<br></marcel.taeumel@hpi.de></marcel.taeumel@hpi.de></marcel.taeumel@hpi.de></div></blockquote></div>