[Feature Request] 64-bit integer primitive type (long and ulong)

[itlancer]

Feature Description

64-bit integer primitive data type essential for modern applications and projects. It must have for AIR and could be called long and ulong as in Java.

Such ptimitive types necessary for multiple tasks, for example:

• Faster computing where int and uint too small but Number is too slow.
• Working with files which sizes greater than 4GB (more bytes than a uint can handle).
• Correctly working with "true" long/ulong data with other systems, APIs etc.
• Proper data transfer with native extensions in some cases where 64-bit data types needed.

Tracker links: https://tracker.adobe.com/#/view/AIR-4072990 https://tracker.adobe.com/#/view/FP-3837839

Known Workarounds

Using Number.

[ajwfrost]

We looked at this a little while ago (I'd have thought int64 preferable to long? but let me know what you think...) One of the challenges is around how all the values are stored within the avmplus virtual machine, since we're still supporting 32-bit builds of the runtime which only have 29 bits of storage available for integer values... so we could add support for 64-bit integers in a similar way to how they handle Number values. Not massively efficient though..

But yes it's something we would like to add in to the runtime at some point!

[itlancer]

@ajwfrost int64 would be great. I think for 32-bit builds new type could use Number under the hood without extra performance. But for 64-bit builds it should use true 64-bit integers for maximum efficiency. Cause most of applications which need such functionalities and works with 4GB+ files are 64-bit.

[ajwfrost]

Sure ... just for completeness (in case anyone is interested):

for 32-bit builds new type could use Number under the hood

We can't use "Number" to represent a 64-bit integer, because even a double-precision floating point representation can't actually represent all of the integers present in an uint64 type. But, what I meant was, we can use the same mechanism that the avmplus code currently uses when storing a 'Number' type ('double' in C++)

Will also look at the float support (single-precision floating points) which had been added a while back but I don't think was ever released...

And I am wondering whether we could have 64-bit atom types even on a 32-bit build of AIR. TBH it's probably only Windows where people actually still use 32-bit much, and I had wondered whether we should be switching to 64-bit by default for them...

[itlancer]

@ajwfrost Thanks for info! Default AIR builds for Windows could be 64-bit but we still have a lot of users with only 32-bit OSes so it still should be supported by AIR.

[2jfw]

So many platforms have already abandonded 32-bit that I would vote for also no longer supporting it. Windows 11 does also not support 32-bit so it is just a matter of time that 32-bit is completely obsolete anyways. It would make maintenace etc easier and less verbose so just follow the trend and let go on this..

[johnou]

@ajwfrost we are interested in long support as well, in particular ByteArray.readLong()

[ajwfrost]

Thanks -> quick update, having looked back on this thread: we did look at moving the avmplus into using 64-bit atom types on a 32-bit build, but that just raises a huge number of problems.. and we can't drop the 32-bit Windows target because a lot of AIR applications that are already installed on machines, or that are available as .msi files, are going to need that. Will have to look at how we can perhaps have two packages that sit alongside each other so that we can start a transition here.

Anyway -> in terms of 64-bit "long" and "ulong" support, this will of course mean that we need to change the compiler too, as well as the ABC format and the avmplus code. One issue that's been highlighted is that when we change the compiler, it causes a problem for people who don't use the same compiler... e.g. Flex or Royale developers. Not 100% sure what could be done there (particularly if targetting JavaScript output .. there's perhaps a 'BigInt' wrapper library that could be used?)

I think this sort of change is definitely needed though! Somewhere there was a discussion about other new data types, can't find it currently but there's still a possibility to have 'float' as single-prevision .. ah, found it, github had helpfully hidden a few of the topics under this one: https://github.com/airsdk/Adobe-Runtime-Support/discussions/2152#discussioncomment-3684488

We'll look at how/when to do this...

[johnou]

@ajwfrost we tried working around this by creating a wrapper..

public class LongWrapper {
    private var high:int;
    private var low:uint;

    public function readFromByteArray(byteArray:ByteArray):void {
        high = byteArray.readInt();
        low = byteArray.readUnsignedInt();
    }

    public function writeToByteArray(byteArray:ByteArray):void {
        byteArray.writeInt(high);
        byteArray.writeUnsignedInt(low);
    }

    public function equals(other:LongWrapper):Boolean {
        return (this.high == other.high) && (this.low == other.low);
    }
}

which then complicates things as we cannot override equals (reference equality?) so vector operations won't work out of the box etc.

might look into using Number instead..