You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2018/06/25 06:07:07 UTC
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
Of course, I could be wrong...
-Alex
On 6/24/18, 12:25 PM, "harbs@apache.org" <ha...@apache.org> wrote:
This is an automated email from the ASF dual-hosted git repository.
harbs pushed a commit to branch develop
in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0
The following commit(s) were added to refs/heads/develop by this push:
new ce95546 Shifting 24 bits converted to negative int value
ce95546 is described below
commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
Author: Harbs <ha...@in-tools.com>
AuthorDate: Sun Jun 24 22:25:37 2018 +0300
Shifting 24 bits converted to negative int value
---
.../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
index c430369..fad4ea3 100644
--- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
+++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
@@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
{
var arr:Uint8Array = getTypedArray();
if(endian == Endian.BIG_ENDIAN){
- return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
+ return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
} else {
- return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
+ return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
}
}
}
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Greg Dove <gr...@gmail.com>.
I think the most robust way to address this is to have some more unit tests
covering the overlfow cases or whatever edge cases are present in the md5
code that cause the issue. It should be the fastest way to hone in on
things.
I know other languages that compile to js (and other targets) do this (I
contributed from the sidelines to one of them in the past and found the
tests to be very helpful).
On Tue, Jun 26, 2018 at 5:29 AM Harbs <ha...@gmail.com> wrote:
> I think it’s a type conversion. Maybe there’s no overhead if the value
> happens to already be an unsigned int. Don’t know…
>
> > On Jun 25, 2018, at 8:23 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > I'm still pondering if there are issues. More related to lots of
> integer math like is used in MD5.
> >
> > FWIW, I'm not clear that ">>> 0" actually results in a call to the CPU's
> shift operator or even the Browser's shift code. It might just be used for
> type inferencing.
> >
> > My 2 cents,
> > -Alex
> >
> > On 6/25/18, 10:18 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >
> > I already switched to using the unsigned shift operator. I’m more
> trying to understand if there are issues I’m not getting.
> >
> > I wonder if all the uint read methods should be using the unsigned
> shift operator to ensure the number type is an unsigned integer before
> returning the value, but I’m not sure it really has an effect on the bits.
> Adding an extra operation which doesn’t do anything is silly.
> >
> > If you have any ideas for tests which could be effected by bits that
> are set wrong somehow, I’d love to add those…
> >
> > Regarding performance, it does seem like shift operators are for the
> most part more efficient, but it depends on the browser. Safari had an
> improvement of between 2 and three times for 16 bit conversions. Chrome was
> actually a bit slower with short operators until the enable-profiling flag
> was enabled. Then shift operators where about 50% faster. Of course, <<24
> >>0 is two operations instead of one, so I’m guessing that performance
> gains over multiplication will be less (but I could be wrong).
> >
> > Thanks,
> > Harbs
> >
> >> On Jun 25, 2018, at 8:08 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>
> >> My main concern is having Royale "do the right thing". I believe that
> some of our migrating users have code that uses bit shifting and if it
> doesn't work correctly on JS it would seem a bit ugly to recommend that
> they also use multiplication. If ">>> 0" works, that is something the
> compiler could automatically generate so users don't have to touch
> migrating code that bit shifts unsigned integers.
> >>
> >> If it is really important to you to use multiplication in BinaryData,
> fine, but I think folks will eventually notice and wonder why.
> >>
> >> I don't know how the browsers actually work these days or will work in
> the future, but I'm more likely to bet that they will optimize bit shifting
> if we can help them infer types. I'm not sure they can as easily infer
> types from multiplication as from actual bit shifting.
> >>
> >> Finally, way back in the day, bit shifting was much faster than
> floating point multiplication, but you never know how much overhead there
> is in the browser runtime.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 6/25/18, 12:57 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com> <mailto:harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>>> wrote:
> >>
> >> I didn’t find that >>> 0 trick before. Interesting.
> >>
> >> I guess I could switch the calculation to (val << 24) >>> 0 which
> seems to give the correct results, but I’m really not sure what your
> concern is with the multiplication. All we’re doing is getting the numeric
> value of the last byte. I don’t see how we could get a different result
> after adding the four byte values together.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On Jun 25, 2018, at 10:46 AM, Alex Harui <aharui@adobe.com.INVALID
> <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID
> <ma...@adobe.com.INVALID>>> wrote:
> >>>
> >>> Here's an article that might help.
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0
> >>
> >>>
> >>> It's great that you have it working with multiply, but my main concern
> is if existing code being migrated uses shift operators and whether JS will
> produce different results than SWF. Maybe we need to do the >>> 0 trick
> mentioned in this article.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> On 6/24/18, 11:49 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>
> >>> readUnsignedInt() was returning the wrong value when the last bit was
> 1 (i.e. a negative int instead of a large uint). Using multiplication on
> the last byte instead of bit shifting fixed the problem. It works because
> multiplication will always give the same correct positive value. I think
> that’s the simplest way to resolve this.
> >>>
> >>> Thanks,
> >>> Harbs
> >>>
> >>>> On Jun 25, 2018, at 9:32 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>>>
> >>>> Yeah, that article is addressing what I meant by "out of range" or an
> "signed int read". What method is this that you are changing? If this is
> all unsigned, then the issue may not be the shifting, but rather the values
> being tested or the final conversion of the bits to the returned value.
> >>>>
> >>>> IOW, an unsigned int can just plain start as 0xFF000000. And if the
> browser is going to convert that to a signed int (actually, a float, I
> think), then we have to make sure we find the right way to convert that
> value as a uint. It might require stuffing a DataView or even using
> parseFloat. Not sure.
> >>>>
> >>>> My 2 cents,
> >>>> -Alex
> >>>>
> >>>> On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>>
> >>>> It seemed strange to me too. I found this:
> >>>>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0
> >
> >>>>
> >>>>> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>>>>
> >>>>> FWIW, this does not make sense. Shifting to the left shouldn't
> cause sign-bit extending. I suppose it could shift a 1 into the sign bit,
> but that implies a signed int read, or the data was out of range.
> >>>>>
> >>>>> Of course, I could be wrong...
> >>>>> -Alex
> >>>>>
> >>>>> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <
> harbs@apache.org <ma...@apache.org>> wrote:
> >>>>>
> >>>>> This is an automated email from the ASF dual-hosted git repository.
> >>>>>
> >>>>> harbs pushed a commit to branch develop
> >>>>> in repository
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0
> >
> >>>>>
> >>>>>
> >>>>> The following commit(s) were added to refs/heads/develop by this
> push:
> >>>>> new ce95546 Shifting 24 bits converted to negative int value
> >>>>> ce95546 is described below
> >>>>>
> >>>>> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
> >>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
> >>>>> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
> >>>>>
> >>>>> Shifting 24 bits converted to negative int value
> >>>>> ---
> >>>>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> | 4 ++--
> >>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> >>>>> index c430369..fad4ea3 100644
> >>>>> ---
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> >>>>> +++
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> >>>>> @@ -665,9 +665,9 @@ public class BinaryData implements
> IBinaryDataInput, IBinaryDataOutput
> >>>>> {
> >>>>> var arr:Uint8Array = getTypedArray();
> >>>>> if(endian == Endian.BIG_ENDIAN){
> >>>>> - return (arr[_position++] << 24) + (arr[_position++]
> << 16) + ( arr[_position++] << 8) + arr[_position++];
> >>>>> + return (arr[_position++] * 16777216) +
> (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
> >>>>> } else {
> >>>>> - return arr[_position++] + ( arr[_position++] << 8)
> + (arr[_position++] << 16) + (arr[_position++] << 24)
> >>>>> + return arr[_position++] + ( arr[_position++] << 8)
> + (arr[_position++] << 16) + (arr[_position++] * 16777216)
> >>>>> }
> >>>>> }
> >>>>> }
>
>
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Harbs <ha...@gmail.com>.
I think it’s a type conversion. Maybe there’s no overhead if the value happens to already be an unsigned int. Don’t know…
> On Jun 25, 2018, at 8:23 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I'm still pondering if there are issues. More related to lots of integer math like is used in MD5.
>
> FWIW, I'm not clear that ">>> 0" actually results in a call to the CPU's shift operator or even the Browser's shift code. It might just be used for type inferencing.
>
> My 2 cents,
> -Alex
>
> On 6/25/18, 10:18 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> I already switched to using the unsigned shift operator. I’m more trying to understand if there are issues I’m not getting.
>
> I wonder if all the uint read methods should be using the unsigned shift operator to ensure the number type is an unsigned integer before returning the value, but I’m not sure it really has an effect on the bits. Adding an extra operation which doesn’t do anything is silly.
>
> If you have any ideas for tests which could be effected by bits that are set wrong somehow, I’d love to add those…
>
> Regarding performance, it does seem like shift operators are for the most part more efficient, but it depends on the browser. Safari had an improvement of between 2 and three times for 16 bit conversions. Chrome was actually a bit slower with short operators until the enable-profiling flag was enabled. Then shift operators where about 50% faster. Of course, <<24 >>0 is two operations instead of one, so I’m guessing that performance gains over multiplication will be less (but I could be wrong).
>
> Thanks,
> Harbs
>
>> On Jun 25, 2018, at 8:08 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> My main concern is having Royale "do the right thing". I believe that some of our migrating users have code that uses bit shifting and if it doesn't work correctly on JS it would seem a bit ugly to recommend that they also use multiplication. If ">>> 0" works, that is something the compiler could automatically generate so users don't have to touch migrating code that bit shifts unsigned integers.
>>
>> If it is really important to you to use multiplication in BinaryData, fine, but I think folks will eventually notice and wonder why.
>>
>> I don't know how the browsers actually work these days or will work in the future, but I'm more likely to bet that they will optimize bit shifting if we can help them infer types. I'm not sure they can as easily infer types from multiplication as from actual bit shifting.
>>
>> Finally, way back in the day, bit shifting was much faster than floating point multiplication, but you never know how much overhead there is in the browser runtime.
>>
>> My 2 cents,
>> -Alex
>>
>> On 6/25/18, 12:57 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>
>> I didn’t find that >>> 0 trick before. Interesting.
>>
>> I guess I could switch the calculation to (val << 24) >>> 0 which seems to give the correct results, but I’m really not sure what your concern is with the multiplication. All we’re doing is getting the numeric value of the last byte. I don’t see how we could get a different result after adding the four byte values together.
>>
>> Thanks,
>> Harbs
>>
>>> On Jun 25, 2018, at 10:46 AM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>> wrote:
>>>
>>> Here's an article that might help. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0>>
>>>
>>> It's great that you have it working with multiply, but my main concern is if existing code being migrated uses shift operators and whether JS will produce different results than SWF. Maybe we need to do the >>> 0 trick mentioned in this article.
>>>
>>> HTH,
>>> -Alex
>>>
>>> On 6/24/18, 11:49 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> readUnsignedInt() was returning the wrong value when the last bit was 1 (i.e. a negative int instead of a large uint). Using multiplication on the last byte instead of bit shifting fixed the problem. It works because multiplication will always give the same correct positive value. I think that’s the simplest way to resolve this.
>>>
>>> Thanks,
>>> Harbs
>>>
>>>> On Jun 25, 2018, at 9:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> Yeah, that article is addressing what I meant by "out of range" or an "signed int read". What method is this that you are changing? If this is all unsigned, then the issue may not be the shifting, but rather the values being tested or the final conversion of the bits to the returned value.
>>>>
>>>> IOW, an unsigned int can just plain start as 0xFF000000. And if the browser is going to convert that to a signed int (actually, a float, I think), then we have to make sure we find the right way to convert that value as a uint. It might require stuffing a DataView or even using parseFloat. Not sure.
>>>>
>>>> My 2 cents,
>>>> -Alex
>>>>
>>>> On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>> It seemed strange to me too. I found this:
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0>
>>>>
>>>>> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>>
>>>>> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>>>>>
>>>>> Of course, I could be wrong...
>>>>> -Alex
>>>>>
>>>>> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>>>>
>>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>>
>>>>> harbs pushed a commit to branch develop
>>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>>>>>
>>>>>
>>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>>> new ce95546 Shifting 24 bits converted to negative int value
>>>>> ce95546 is described below
>>>>>
>>>>> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>>>>> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>>>>>
>>>>> Shifting 24 bits converted to negative int value
>>>>> ---
>>>>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>>> index c430369..fad4ea3 100644
>>>>> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>>> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
>>>>> {
>>>>> var arr:Uint8Array = getTypedArray();
>>>>> if(endian == Endian.BIG_ENDIAN){
>>>>> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>>>> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>>>> } else {
>>>>> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
>>>>> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
>>>>> }
>>>>> }
>>>>> }
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm still pondering if there are issues. More related to lots of integer math like is used in MD5.
FWIW, I'm not clear that ">>> 0" actually results in a call to the CPU's shift operator or even the Browser's shift code. It might just be used for type inferencing.
My 2 cents,
-Alex
On 6/25/18, 10:18 AM, "Harbs" <ha...@gmail.com> wrote:
I already switched to using the unsigned shift operator. I’m more trying to understand if there are issues I’m not getting.
I wonder if all the uint read methods should be using the unsigned shift operator to ensure the number type is an unsigned integer before returning the value, but I’m not sure it really has an effect on the bits. Adding an extra operation which doesn’t do anything is silly.
If you have any ideas for tests which could be effected by bits that are set wrong somehow, I’d love to add those…
Regarding performance, it does seem like shift operators are for the most part more efficient, but it depends on the browser. Safari had an improvement of between 2 and three times for 16 bit conversions. Chrome was actually a bit slower with short operators until the enable-profiling flag was enabled. Then shift operators where about 50% faster. Of course, <<24 >>0 is two operations instead of one, so I’m guessing that performance gains over multiplication will be less (but I could be wrong).
Thanks,
Harbs
> On Jun 25, 2018, at 8:08 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> My main concern is having Royale "do the right thing". I believe that some of our migrating users have code that uses bit shifting and if it doesn't work correctly on JS it would seem a bit ugly to recommend that they also use multiplication. If ">>> 0" works, that is something the compiler could automatically generate so users don't have to touch migrating code that bit shifts unsigned integers.
>
> If it is really important to you to use multiplication in BinaryData, fine, but I think folks will eventually notice and wonder why.
>
> I don't know how the browsers actually work these days or will work in the future, but I'm more likely to bet that they will optimize bit shifting if we can help them infer types. I'm not sure they can as easily infer types from multiplication as from actual bit shifting.
>
> Finally, way back in the day, bit shifting was much faster than floating point multiplication, but you never know how much overhead there is in the browser runtime.
>
> My 2 cents,
> -Alex
>
> On 6/25/18, 12:57 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> I didn’t find that >>> 0 trick before. Interesting.
>
> I guess I could switch the calculation to (val << 24) >>> 0 which seems to give the correct results, but I’m really not sure what your concern is with the multiplication. All we’re doing is getting the numeric value of the last byte. I don’t see how we could get a different result after adding the four byte values together.
>
> Thanks,
> Harbs
>
>> On Jun 25, 2018, at 10:46 AM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>
>> Here's an article that might help. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0>
>>
>> It's great that you have it working with multiply, but my main concern is if existing code being migrated uses shift operators and whether JS will produce different results than SWF. Maybe we need to do the >>> 0 trick mentioned in this article.
>>
>> HTH,
>> -Alex
>>
>> On 6/24/18, 11:49 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> readUnsignedInt() was returning the wrong value when the last bit was 1 (i.e. a negative int instead of a large uint). Using multiplication on the last byte instead of bit shifting fixed the problem. It works because multiplication will always give the same correct positive value. I think that’s the simplest way to resolve this.
>>
>> Thanks,
>> Harbs
>>
>>> On Jun 25, 2018, at 9:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Yeah, that article is addressing what I meant by "out of range" or an "signed int read". What method is this that you are changing? If this is all unsigned, then the issue may not be the shifting, but rather the values being tested or the final conversion of the bits to the returned value.
>>>
>>> IOW, an unsigned int can just plain start as 0xFF000000. And if the browser is going to convert that to a signed int (actually, a float, I think), then we have to make sure we find the right way to convert that value as a uint. It might require stuffing a DataView or even using parseFloat. Not sure.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> It seemed strange to me too. I found this:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0>
>>>
>>>> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>>>>
>>>> Of course, I could be wrong...
>>>> -Alex
>>>>
>>>> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>
>>>> harbs pushed a commit to branch develop
>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>> new ce95546 Shifting 24 bits converted to negative int value
>>>> ce95546 is described below
>>>>
>>>> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>>>> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>>>>
>>>> Shifting 24 bits converted to negative int value
>>>> ---
>>>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>> index c430369..fad4ea3 100644
>>>> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
>>>> {
>>>> var arr:Uint8Array = getTypedArray();
>>>> if(endian == Endian.BIG_ENDIAN){
>>>> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>>> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>>> } else {
>>>> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
>>>> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
>>>> }
>>>> }
>>>> }
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Harbs <ha...@gmail.com>.
I already switched to using the unsigned shift operator. I’m more trying to understand if there are issues I’m not getting.
I wonder if all the uint read methods should be using the unsigned shift operator to ensure the number type is an unsigned integer before returning the value, but I’m not sure it really has an effect on the bits. Adding an extra operation which doesn’t do anything is silly.
If you have any ideas for tests which could be effected by bits that are set wrong somehow, I’d love to add those…
Regarding performance, it does seem like shift operators are for the most part more efficient, but it depends on the browser. Safari had an improvement of between 2 and three times for 16 bit conversions. Chrome was actually a bit slower with short operators until the enable-profiling flag was enabled. Then shift operators where about 50% faster. Of course, <<24 >>0 is two operations instead of one, so I’m guessing that performance gains over multiplication will be less (but I could be wrong).
Thanks,
Harbs
> On Jun 25, 2018, at 8:08 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> My main concern is having Royale "do the right thing". I believe that some of our migrating users have code that uses bit shifting and if it doesn't work correctly on JS it would seem a bit ugly to recommend that they also use multiplication. If ">>> 0" works, that is something the compiler could automatically generate so users don't have to touch migrating code that bit shifts unsigned integers.
>
> If it is really important to you to use multiplication in BinaryData, fine, but I think folks will eventually notice and wonder why.
>
> I don't know how the browsers actually work these days or will work in the future, but I'm more likely to bet that they will optimize bit shifting if we can help them infer types. I'm not sure they can as easily infer types from multiplication as from actual bit shifting.
>
> Finally, way back in the day, bit shifting was much faster than floating point multiplication, but you never know how much overhead there is in the browser runtime.
>
> My 2 cents,
> -Alex
>
> On 6/25/18, 12:57 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> I didn’t find that >>> 0 trick before. Interesting.
>
> I guess I could switch the calculation to (val << 24) >>> 0 which seems to give the correct results, but I’m really not sure what your concern is with the multiplication. All we’re doing is getting the numeric value of the last byte. I don’t see how we could get a different result after adding the four byte values together.
>
> Thanks,
> Harbs
>
>> On Jun 25, 2018, at 10:46 AM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>
>> Here's an article that might help. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0>
>>
>> It's great that you have it working with multiply, but my main concern is if existing code being migrated uses shift operators and whether JS will produce different results than SWF. Maybe we need to do the >>> 0 trick mentioned in this article.
>>
>> HTH,
>> -Alex
>>
>> On 6/24/18, 11:49 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> readUnsignedInt() was returning the wrong value when the last bit was 1 (i.e. a negative int instead of a large uint). Using multiplication on the last byte instead of bit shifting fixed the problem. It works because multiplication will always give the same correct positive value. I think that’s the simplest way to resolve this.
>>
>> Thanks,
>> Harbs
>>
>>> On Jun 25, 2018, at 9:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Yeah, that article is addressing what I meant by "out of range" or an "signed int read". What method is this that you are changing? If this is all unsigned, then the issue may not be the shifting, but rather the values being tested or the final conversion of the bits to the returned value.
>>>
>>> IOW, an unsigned int can just plain start as 0xFF000000. And if the browser is going to convert that to a signed int (actually, a float, I think), then we have to make sure we find the right way to convert that value as a uint. It might require stuffing a DataView or even using parseFloat. Not sure.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> It seemed strange to me too. I found this:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0>
>>>
>>>> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>>>>
>>>> Of course, I could be wrong...
>>>> -Alex
>>>>
>>>> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>
>>>> harbs pushed a commit to branch develop
>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>> new ce95546 Shifting 24 bits converted to negative int value
>>>> ce95546 is described below
>>>>
>>>> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>>>> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>>>>
>>>> Shifting 24 bits converted to negative int value
>>>> ---
>>>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>> index c430369..fad4ea3 100644
>>>> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>>> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
>>>> {
>>>> var arr:Uint8Array = getTypedArray();
>>>> if(endian == Endian.BIG_ENDIAN){
>>>> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>>> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>>> } else {
>>>> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
>>>> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
>>>> }
>>>> }
>>>> }
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Alex Harui <ah...@adobe.com.INVALID>.
My main concern is having Royale "do the right thing". I believe that some of our migrating users have code that uses bit shifting and if it doesn't work correctly on JS it would seem a bit ugly to recommend that they also use multiplication. If ">>> 0" works, that is something the compiler could automatically generate so users don't have to touch migrating code that bit shifts unsigned integers.
If it is really important to you to use multiplication in BinaryData, fine, but I think folks will eventually notice and wonder why.
I don't know how the browsers actually work these days or will work in the future, but I'm more likely to bet that they will optimize bit shifting if we can help them infer types. I'm not sure they can as easily infer types from multiplication as from actual bit shifting.
Finally, way back in the day, bit shifting was much faster than floating point multiplication, but you never know how much overhead there is in the browser runtime.
My 2 cents,
-Alex
On 6/25/18, 12:57 AM, "Harbs" <ha...@gmail.com> wrote:
I didn’t find that >>> 0 trick before. Interesting.
I guess I could switch the calculation to (val << 24) >>> 0 which seems to give the correct results, but I’m really not sure what your concern is with the multiplication. All we’re doing is getting the numeric value of the last byte. I don’t see how we could get a different result after adding the four byte values together.
Thanks,
Harbs
> On Jun 25, 2018, at 10:46 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Here's an article that might help. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1&data=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878&sdata=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D&reserved=0
>
> It's great that you have it working with multiply, but my main concern is if existing code being migrated uses shift operators and whether JS will produce different results than SWF. Maybe we need to do the >>> 0 trick mentioned in this article.
>
> HTH,
> -Alex
>
> On 6/24/18, 11:49 PM, "Harbs" <ha...@gmail.com> wrote:
>
> readUnsignedInt() was returning the wrong value when the last bit was 1 (i.e. a negative int instead of a large uint). Using multiplication on the last byte instead of bit shifting fixed the problem. It works because multiplication will always give the same correct positive value. I think that’s the simplest way to resolve this.
>
> Thanks,
> Harbs
>
>> On Jun 25, 2018, at 9:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yeah, that article is addressing what I meant by "out of range" or an "signed int read". What method is this that you are changing? If this is all unsigned, then the issue may not be the shifting, but rather the values being tested or the final conversion of the bits to the returned value.
>>
>> IOW, an unsigned int can just plain start as 0xFF000000. And if the browser is going to convert that to a signed int (actually, a float, I think), then we have to make sure we find the right way to convert that value as a uint. It might require stuffing a DataView or even using parseFloat. Not sure.
>>
>> My 2 cents,
>> -Alex
>>
>> On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> It seemed strange to me too. I found this:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0>
>>
>>> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>>>
>>> Of course, I could be wrong...
>>> -Alex
>>>
>>> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> harbs pushed a commit to branch develop
>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>>>
>>>
>>> The following commit(s) were added to refs/heads/develop by this push:
>>> new ce95546 Shifting 24 bits converted to negative int value
>>> ce95546 is described below
>>>
>>> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>>> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>>>
>>> Shifting 24 bits converted to negative int value
>>> ---
>>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>> index c430369..fad4ea3 100644
>>> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
>>> {
>>> var arr:Uint8Array = getTypedArray();
>>> if(endian == Endian.BIG_ENDIAN){
>>> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>> } else {
>>> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
>>> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
>>> }
>>> }
>>> }
>>
>>
>>
>
>
>
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Harbs <ha...@gmail.com>.
I didn’t find that >>> 0 trick before. Interesting.
I guess I could switch the calculation to (val << 24) >>> 0 which seems to give the correct results, but I’m really not sure what your concern is with the multiplication. All we’re doing is getting the numeric value of the last byte. I don’t see how we could get a different result after adding the four byte values together.
Thanks,
Harbs
> On Jun 25, 2018, at 10:46 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Here's an article that might help. https://stackoverflow.com/questions/6798111/bitwise-operations-on-32-bit-unsigned-ints?rq=1
>
> It's great that you have it working with multiply, but my main concern is if existing code being migrated uses shift operators and whether JS will produce different results than SWF. Maybe we need to do the >>> 0 trick mentioned in this article.
>
> HTH,
> -Alex
>
> On 6/24/18, 11:49 PM, "Harbs" <ha...@gmail.com> wrote:
>
> readUnsignedInt() was returning the wrong value when the last bit was 1 (i.e. a negative int instead of a large uint). Using multiplication on the last byte instead of bit shifting fixed the problem. It works because multiplication will always give the same correct positive value. I think that’s the simplest way to resolve this.
>
> Thanks,
> Harbs
>
>> On Jun 25, 2018, at 9:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yeah, that article is addressing what I meant by "out of range" or an "signed int read". What method is this that you are changing? If this is all unsigned, then the issue may not be the shifting, but rather the values being tested or the final conversion of the bits to the returned value.
>>
>> IOW, an unsigned int can just plain start as 0xFF000000. And if the browser is going to convert that to a signed int (actually, a float, I think), then we have to make sure we find the right way to convert that value as a uint. It might require stuffing a DataView or even using parseFloat. Not sure.
>>
>> My 2 cents,
>> -Alex
>>
>> On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> It seemed strange to me too. I found this:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0>
>>
>>> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>>>
>>> Of course, I could be wrong...
>>> -Alex
>>>
>>> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> harbs pushed a commit to branch develop
>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>>>
>>>
>>> The following commit(s) were added to refs/heads/develop by this push:
>>> new ce95546 Shifting 24 bits converted to negative int value
>>> ce95546 is described below
>>>
>>> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>>> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>>>
>>> Shifting 24 bits converted to negative int value
>>> ---
>>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>> index c430369..fad4ea3 100644
>>> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
>>> {
>>> var arr:Uint8Array = getTypedArray();
>>> if(endian == Endian.BIG_ENDIAN){
>>> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>>> } else {
>>> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
>>> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
>>> }
>>> }
>>> }
>>
>>
>>
>
>
>
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Here's an article that might help. https://stackoverflow.com/questions/6798111/bitwise-operations-on-32-bit-unsigned-ints?rq=1
It's great that you have it working with multiply, but my main concern is if existing code being migrated uses shift operators and whether JS will produce different results than SWF. Maybe we need to do the >>> 0 trick mentioned in this article.
HTH,
-Alex
On 6/24/18, 11:49 PM, "Harbs" <ha...@gmail.com> wrote:
readUnsignedInt() was returning the wrong value when the last bit was 1 (i.e. a negative int instead of a large uint). Using multiplication on the last byte instead of bit shifting fixed the problem. It works because multiplication will always give the same correct positive value. I think that’s the simplest way to resolve this.
Thanks,
Harbs
> On Jun 25, 2018, at 9:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yeah, that article is addressing what I meant by "out of range" or an "signed int read". What method is this that you are changing? If this is all unsigned, then the issue may not be the shifting, but rather the values being tested or the final conversion of the bits to the returned value.
>
> IOW, an unsigned int can just plain start as 0xFF000000. And if the browser is going to convert that to a signed int (actually, a float, I think), then we have to make sure we find the right way to convert that value as a uint. It might require stuffing a DataView or even using parseFloat. Not sure.
>
> My 2 cents,
> -Alex
>
> On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
>
> It seemed strange to me too. I found this:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0>
>
>> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>>
>> Of course, I could be wrong...
>> -Alex
>>
>> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> harbs pushed a commit to branch develop
>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>>
>>
>> The following commit(s) were added to refs/heads/develop by this push:
>> new ce95546 Shifting 24 bits converted to negative int value
>> ce95546 is described below
>>
>> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>>
>> Shifting 24 bits converted to negative int value
>> ---
>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>> index c430369..fad4ea3 100644
>> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
>> {
>> var arr:Uint8Array = getTypedArray();
>> if(endian == Endian.BIG_ENDIAN){
>> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>> } else {
>> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
>> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
>> }
>> }
>> }
>
>
>
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Harbs <ha...@gmail.com>.
readUnsignedInt() was returning the wrong value when the last bit was 1 (i.e. a negative int instead of a large uint). Using multiplication on the last byte instead of bit shifting fixed the problem. It works because multiplication will always give the same correct positive value. I think that’s the simplest way to resolve this.
Thanks,
Harbs
> On Jun 25, 2018, at 9:32 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yeah, that article is addressing what I meant by "out of range" or an "signed int read". What method is this that you are changing? If this is all unsigned, then the issue may not be the shifting, but rather the values being tested or the final conversion of the bits to the returned value.
>
> IOW, an unsigned int can just plain start as 0xFF000000. And if the browser is going to convert that to a signed int (actually, a float, I think), then we have to make sure we find the right way to convert that value as a uint. It might require stuffing a DataView or even using parseFloat. Not sure.
>
> My 2 cents,
> -Alex
>
> On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
>
> It seemed strange to me too. I found this:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0>
>
>> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>>
>> Of course, I could be wrong...
>> -Alex
>>
>> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> harbs pushed a commit to branch develop
>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>>
>>
>> The following commit(s) were added to refs/heads/develop by this push:
>> new ce95546 Shifting 24 bits converted to negative int value
>> ce95546 is described below
>>
>> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>>
>> Shifting 24 bits converted to negative int value
>> ---
>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>> index c430369..fad4ea3 100644
>> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
>> {
>> var arr:Uint8Array = getTypedArray();
>> if(endian == Endian.BIG_ENDIAN){
>> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
>> } else {
>> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
>> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
>> }
>> }
>> }
>
>
>
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yeah, that article is addressing what I meant by "out of range" or an "signed int read". What method is this that you are changing? If this is all unsigned, then the issue may not be the shifting, but rather the values being tested or the final conversion of the bits to the returned value.
IOW, an unsigned int can just plain start as 0xFF000000. And if the browser is going to convert that to a signed int (actually, a float, I think), then we have to make sure we find the right way to convert that value as a uint. It might require stuffing a DataView or even using parseFloat. Not sure.
My 2 cents,
-Alex
On 6/24/18, 11:11 PM, "Harbs" <ha...@gmail.com> wrote:
It seemed strange to me too. I found this:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number&data=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700&sdata=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D&reserved=0>
> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>
> Of course, I could be wrong...
> -Alex
>
> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> harbs pushed a commit to branch develop
> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>
>
> The following commit(s) were added to refs/heads/develop by this push:
> new ce95546 Shifting 24 bits converted to negative int value
> ce95546 is described below
>
> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>
> Shifting 24 bits converted to negative int value
> ---
> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> index c430369..fad4ea3 100644
> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
> {
> var arr:Uint8Array = getTypedArray();
> if(endian == Endian.BIG_ENDIAN){
> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
> } else {
> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
> }
> }
> }
Re: [royale-asjs] branch develop updated: Shifting 24 bits converted
to negative int value
Posted by Harbs <ha...@gmail.com>.
It seemed strange to me too. I found this:
https://stackoverflow.com/questions/18034974/why-in-javascript-expression-255-24-is-a-negative-number <https://stackoverflow.com/questions/18034974/why-in-javascript-expression-255-24-is-a-negative-number>
> On Jun 25, 2018, at 9:07 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> FWIW, this does not make sense. Shifting to the left shouldn't cause sign-bit extending. I suppose it could shift a 1 into the sign bit, but that implies a signed int read, or the data was out of range.
>
> Of course, I could be wrong...
> -Alex
>
> On 6/24/18, 12:25 PM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> harbs pushed a commit to branch develop
> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568&sdata=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D&reserved=0>
>
>
> The following commit(s) were added to refs/heads/develop by this push:
> new ce95546 Shifting 24 bits converted to negative int value
> ce95546 is described below
>
> commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
> AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>
> Shifting 24 bits converted to negative int value
> ---
> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> index c430369..fad4ea3 100644
> --- a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> +++ b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, IBinaryDataOutput
> {
> var arr:Uint8Array = getTypedArray();
> if(endian == Endian.BIG_ENDIAN){
> - return (arr[_position++] << 24) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
> + return (arr[_position++] * 16777216) + (arr[_position++] << 16) + ( arr[_position++] << 8) + arr[_position++];
> } else {
> - return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] << 24)
> + return arr[_position++] + ( arr[_position++] << 8) + (arr[_position++] << 16) + (arr[_position++] * 16777216)
> }
> }
> }