Quote from: calc84maniac on October 01, 2011, 11:34:47 pm

Quote from: Runer112 on September 30, 2011, 06:21:06 pm

That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here. Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.

Directly using pushing/popping can definitely cause problems in the middle of expressions, and in For(const) loops for example. There are too many things subject to change in the implementation of Axe for direct stack access not to be potentially buggy unless you know a lot about the inner workings of Axe. I think Asm() will suffice for crazy hackage.

Edit: Well, I suppose Axe could keep track of all pushes/pops as well as which ones are manual and which ones are internal. It could then error if it tries to internally pop a manual push or manually pop an internal push. That's fairly safe, I guess.

Not good if someone wants that to happen though

If you're at the point where you want to access internal Axe values, you're probably better off using Asm() since that would be Axe-version-specific behavior.

Heya and welcome here! I'm unsure what were the plans for 32 bits numbers, but I think Runer112 posted a routine that allowed combining two numbers into one to make 32 bit ones, sort of. However I'm unsure how reliable it was and where it is on the forums. Native 32 bit support would definitively be cool for those who needs high values such as scores (such as in SMB series where scores easily reach the hundred thousands) or RPGs where damages reach 9999 and where calculating defense/atk/elemental properties causes them to overflow past 65535 or 32767 like in certain SNES RPGs.

Any chance we will see 32 bit numbers soon ?

I think Runer112 posted a routine that allowed combining two numbers into one to make 32 bit ones, sort of.

Yes. Here it is.

Thanks

IMPORTANT SYNTAX CHANGE
I am planning to make a non-minor syntax change in the next version.  If anyone is opposed to the following, please let me know now.  This will likely cause incompatibility with a few programs, but its a very easy correction to make to your program.

The change involves the Data() command with 2-byte values.  The current syntax is Data(C1,C2^r,C3) to indicate that C1 and C3 are taken to be single byte values whereas C2 is taken to be a 2 byte value.  This works okay for now because C1 and C2 are constants or constant expressions but this syntax does not work with other expressions because you could have an expression that ends with an R, like for instance nib{}^r and it would be impossible to tell if you meant nib{} as a 2 byte number, or nib{}r as a 1 byte number.

Now given that, the Data command still only takes constants, but I am adding a new command for sequential data writing that CAN take expressions, and I would like the 2 commands to be consistent.  My current idea is that any expression fully enclosed in extra parenthesis will be taken as a 2 byte number and otherwise a 1 byte number.  In the case of Data, this would look like: Data(C1,(C2),C3)

I personally think this is more readable anyway and easier to type since you don't have to go through any menus.  Any thoughts or other suggestions?

I could go either way. I don't like the idea of losing the backwards compatibility, but on the other hand I hate typing the r every time =/ On the other hand (again) I don't use it much for large scale data entry anyway which I just do on the computer so maybe it's ok

I wouldn't think it's misleading. If you documented the correct way of doing it as ()^r, I think this should solve most problems. New users wouldn't even think about using the old syntax because they wouldn't know it exists. And old users would be familiar with the change and would know that, since Data() used to work only with constants, you can only use the old 2-byte indicator syntax with constants. I would say that using () to specify 2-byte values carries its own problems anyways, since most programmers should know that a plain extra set of parentheses should do nothing to the code.

That sounds awesome! I guess my only question about it is if there will be a way to draw the image with logic other than overwrite, as it might be nice to be able to draw large sprites that combine nicely with the background in games and such.

And don't forget to browse the Axe issue tracker thingy if you ever want ideas for what to fix/optimize/add. I guess the first two are more important, but the third one is always good to have content added from as well. Especially if there are small, easy things to add that would still be awesome.


EDIT: Oh, and are you completely getting rid of the old command? Because it might still be useful to some due to not requiring a large routine for things that don't really need amazing clipping logic or speed.