mozilla/shumway — comment on commit dea2d3475cdf53fa2d2b52b9f44a2fe02b3a94c8
File: src/avm2/avm2.js line 55
By davidflanagan:

On 1/7/12 10:33 PM, Michael Bebenita wrote:
> Unfortunately the spec doesn't match reality, (https://mail.mozilla.org/pipermail/tamarin-devel/2011-January/001601.html) there's no sign extension. So for instance, 0x7F is not -1, but it's in fact 127. See: http://hg.mozilla.org/tamarin-central/file/fbecf6c8a86f/core/AbcParser-inlines.h line 50.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/mozilla/shumway/commit/dea2d3475cdf53fa2d2b52b9f44a2fe02b3a94c8#commitcomment-847200
Crap. I only tested it with one value. (See the third line of output
when you run avm2.js.) readS32() successfully reads a positive and a
negative value, but I guess that might have worked even with Andreas's
old code that just called U32().

So does this mean that the constant 1 takes 1 byte in an ABC file but -1
takes 5 bytes? Strange design choice!

I still think that Andreas's original code might be wrong, since I think
readU32() will always return a postive value, even if the high-order bit
is set, since JS numbers aren't actually 32 bits and won't roll over.

The readDouble() method is broken (at least it appears so with my
minimal testing).

David