Advertisement

Removing @?

Started by October 20, 2014 12:16 AM
7 comments, last by WitchLord 10 years, 1 month ago

I've been working the AngelScript for about 12 months now and am progressively get more tired of the @ symbol. For some reason it always confuses me and trips me up. I've read the documentation a number of times about it, but always seem to struggle with this one aspect of AngelScript. Other than that I've found AngelScript to be really good (except for the lack of a supported JIT compiler, but that's another question).

I was just browsing the AngelScript website and noticed the removal of the @ symbol under the "Work in progress" section, which made me pretty happy. Why wasn't this decision made earlier? I would love to see all ref types treated as handles. Aren't they almost the same thing anyway?

Is there a reason though why this change is under the "long term goals" and how "long term" are we talking here?

Wouldn't Blind Mind's JIT Compiler count as a supported JIT Compiler for AngelScript? :)
I don't remove the @ because it would completely break the backwards compatibility. I'm not yet ready to stop evolution of version 2.x in favor of completely new version 3.x.
I may eventually create an engine property that would allow the application to decide whether the symbol should be used or not, but it will depend very much on how different the code paths would become. In either way, this is definitely not one of my top priorities, as there are so many other enhancements that I want to add that would be more beneficial to the community.
There is a difference between @ and non-@. If we compare with C++ it is basically the same difference as there is between * and & in C++. A @ can be reassigned and can be null. A non-@ cannot be reassigned and cannot be null.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Advertisement

Thanks for replying.

Guess I'll just have to keep stumbling along with the @ symbol. smile.png

I have seen Blind Mind's JIT Compiler, but I was under the impression that it wasn't much supported any more? They don't seem to update it anymore, so I didn't think it was safe to use something that could become broken when a new version of AngleScript is released as the JIT Compiler would need to be kept up-to-date with every new version of AngelScript, right? It shows the last update to the JIT Compiler was for AngelScript v2.27, which is over a year old now. Not to mention if there was a bug, and nobody is around to fix it, then it kind of leaves you on your own. I consider myself a seasoned C++ programmer, but unfortunately not good enough to try and fix a bug in the JIT Compiler if one existed, or to try and keep it up-to-date with AngleScript if I was to use it.

I have seen Blind Mind's JIT Compiler, but I was under the impression that it wasn't much supported any more? They don't seem to update it anymore, so I didn't think it was safe to use something that could become broken when a new version of AngleScript is released as the JIT Compiler would need to be kept up-to-date with every new version of AngelScript, right? It shows the last update to the JIT Compiler was for AngelScript v2.27, which is over a year old now. Not to mention if there was a bug, and nobody is around to fix it, then it kind of leaves you on your own. I consider myself a seasoned C++ programmer, but unfortunately not good enough to try and fix a bug in the JIT Compiler if one existed, or to try and keep it up-to-date with AngleScript if I was to use it.

There are relatively few changes to Angelscript that require us to update the JIT. Most changes affect how the bytecode is assembled, rather than what a specific bytecode does. When new bytecodes are added, the JIT also falls back to Angelscript execution so it can continue to work. Most bytecode changes are relatively simple and I can easily keep it up to date.

Due to this, the last updated version is just a guarantee of what version works, not an indicator that other versions don't work.

Speaking of which, there was a minor change in the VM in version 2.29.2 that I released yesterday. Let's see how long it takes for ThyReaper to update the JIT compiler to reflect this wink.png

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

There are relatively few changes to Angelscript that require us to update the JIT. Most changes affect how the bytecode is assembled, rather than what a specific bytecode does. When new bytecodes are added, the JIT also falls back to Angelscript execution so it can continue to work. Most bytecode changes are relatively simple and I can easily keep it up to date.

Due to this, the last updated version is just a guarantee of what version works, not an indicator that other versions don't work.

I did not realise this. Please excuse my ignorance. That is good news though, and has persuaded my to take another look at it. I also didn't know that it would fall back to regular AngelScript execution if needed, which is also good to know.

One point I forgot to mention in my previous post was that the JIT Compiler appears to only support Windows and Linux? I am planning on targeting Windows, Mac and Linux. Do you know if the JIT Compiler would build and run on Mac?

Advertisement

One point I forgot to mention in my previous post was that the JIT Compiler appears to only support Windows and Linux? I am planning on targeting Windows, Mac and Linux. Do you know if the JIT Compiler would build and run on Mac?

I'm aware of at least one project on Mac that uses our JIT, though they use GCC. If you use a different compiler it might take a fair amount of work to add support for it.

Speaking of which, there was a minor change in the VM in version 2.29.2 that I released yesterday. Let's see how long it takes for ThyReaper to update the JIT compiler to reflect this wink.png

Looks like that change is simple enough to use a fallback for, at least temporarily. I'll also add native support for power operators at the same time.

Edit: While implementing the power ops, I noticed that overflow isn't detected when constants are resolved (e.g. 500 ** 3000 becomes 0 or #.INF depending, without printing a warning).

I'll look into the problem with the power ops. Thanks for alerting me about it.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

I've added checks for overflow when evaluating the power ops in the constant expressions. The compiler will now give an error in these cases.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

This topic is closed to new replies.

Advertisement