Introduce the new "Int64" data type for 64 bit integer

[ghost]

As a workaround to #208 and doesn't break compatibility with old code that assumed a platform dependent Int.

[objeck]

Thanks for the feedback. I will consider this however I think the first task is changing the VM to a POSIX 64 model on 64-bit Windows. After that, revisit if UInt, Int64 and UInt64 should be added.

[objeck]

Several changes over the days have been made in the posix64_target branch. First, the branch needs to be stabilized; however, most test cases now succeed. Unfortunately, this branch's LSP language server crashes, requiring more testing and debugging.

[objeck]

Several changes over the days have been made in the posix64_target branch. First, the branch needs to be stabilized; however, most test cases now succeed. Unfortunately, this branch's LSP language server crashes, requiring more testing and debugging.

Do not plan to add a new Int64 datatype. Instead, I have extended Windows to support a 64-bit Int type. However, some edge cases need to be tested with the Windows AMD64 JIT compiler, namely the Intel64/AMD64 literal instructions for operations like add, sub, and mul, which take 32-bit encoded literal values.

This can be overcome by loading all literals into registers before use; however, that increases register pressure. This may already be in place as limits were placed on the range of literal values that can be used directly without a register load. I will check these edge cases more as part of the regression.

Updates were merged into the master branch.

[objeck]

TODO

• Test 2d_game_13.obs, end marker, is missing
• LSP server is functional
• Test web server code

[ghost]

I think you should add unsigned types too.

[objeck]

I think you should add unsigned types too.
I think you should add unsigned types too.

An excellent contributor addition, Objeck conceptionally is very simple yet can be extended. Adding unsigned types across the JIT compilers and interrupter is a project. Cross-reference to signed vs. unsigned will need to be explored. The effort is managing the logic in the JIT compilers and nuance in machine output. For example, in an add operation, the machine generation will to updated to detect registers vs. unsigned values.

[ghost]

I think you should add unsigned types too.
I think you should add unsigned types too.

An excellent contributor addition, Objeck conceptionally is very simple yet can be extended. Adding unsigned types across the JIT compilers and interrupter is a project. Cross-reference to signed vs. unsigned will need to be explored. The effort is managing the logic in the JIT compilers and nuance in machine output. For example, in an add operation, the machine generation will to updated to detect registers vs. unsigned values.

I don't understand any of this. But if it's so complex you could consider I have never said anything. Java doesn't have unsigned types anyway (C# has, though).

[objeck]

I think you should add unsigned types too.
I think you should add unsigned types too.

An excellent contributor addition, Objeck conceptionally is very simple yet can be extended. Adding unsigned types across the JIT compilers and interrupter is a project. Cross-reference to signed vs. unsigned will need to be explored. The effort is managing the logic in the JIT compilers and nuance in machine output. For example, in an add operation, the machine generation will to updated to detect registers vs. unsigned values.

I don't understand any of this. But if it's so complex you could consider I have never said anything. Java doesn't have unsigned types anyway (C# has, though).

No problem; look at it this way. For each basic datatype you add, you must define how it interacts with the existing data types. Doing so in a purely interpreted language is easy as you delegate to the underlying Rust/Java/C/C++ code and use their datatypes and defined interactions between those types. When you get to the point where you generate machine code, like Objeck, you have to define the instructions for these interactions, and that is tedious but not necessarily a "complex/hard" computer science problem.

[objeck]

The mainline seems stable, I will add this enhancement to the release notes.