You can do that with interrupts, but I haven't implemented that yet.  And even with interrupts, a few routines like "DispGraph" disable interrupts for the duration of the command during execution.

In the mean time, you can run the codes you want to test in big for loops so they take a measurable amount of time; maybe enough looping to last 5-10 seconds.  That way if there is any difference, you can actually measure it with a stopwatch or clock.

Yeah that's essentially what I'm doing.  I have saftey mode, sandbox mode, and normal mode.

"Sandbox" is actually what I called safety before.

"Saftey" now means that all ram is archived, but ram is not cleared.  Programs remain archived after execution and it returns to the homescreen (so you will notice glitches but everything is still archived).  You'll have to manually unarchive everything you want to put back in RAM yourself (not recommended until a ram clear is performed).

"Normal" is obviously what has been done to date.

Well, I'll wait on that then.

Anyway, I need to propose some safety features and I'd like some feedback.  Here is the idea.  If you select a "safety mode" in the options, the following will occur: All data in ram is archived and an application variable is created to keep track of what it archived (The appvar is also archived).  A dummy variable is also created and is kept in RAM.  Next, after the program is compiled, it is executed within axe parser itself rather than coming back to the home screen.  Once the program finishes, the ram is automatically cleared on the calculator so any corrupted data gets restored to the default.  Next, the appvar gets unarchived and unarchives the variables on its list.  So when the program quits, everything is back to normal.

Now, if the program crashed, and you need to pull the batteries, then the dummy variable gets deleted.  That means that the next time you run axe, it will notify you that you have recovered from a crash and automatically unarchive the programs from the save list to return the calculator back to normal.

This seems like the perfect system to prevent crashes, but its a little too perfect.  What I mean, is that if you start getting used to this, then if it corrupts the memory when safe mode is off, it will be very hard to find where the error is since the error would never be detectable in safety mode.

You might ask "Isn't it possible for axe to automatically detect when memory is corrupted?"  but the problem is that I would need a copy of the entire original RAM to compare it before and after the program is run and that really isn't going to be possible.  And even if it were possible, many assembly programmers often intentionally change non-safe areas of RAM to set flags, alter external variables, run self modifying code, etc.

I'm still going to add this mode anyway, but does anyone else have any other ideas about how to improve safety?

I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?

That will be done using GetCalc().  You can also get Variables, Lists, Strings, Ans, and other RAM variables and locations with this command and it will return a pointer to said object or zero if it doesn't exist.  Therefore, you can also store to these objects.  I'm nowhere near ready to support that command however so don't expect it soon.

That's actually a really good idea to use some variables as variable pointers that are looked up by some routines.  Maybe I will use the "u" "v" "w" variables for this since I'll probably need more than 1 of them.  The only problem with this is that the variables have to be initialized before the program starts.  Otherwise, it will just be something random.  The parser could do it automatically, but then its just adding extra bytes in case you decide to change it again to anything but the default.  It would be really annoying to start every program with L6->u to do any drawing and it might not make sense for beginners.

I could always make the variable location part of the self modifying code so it already starts initialized without using extra memory, but then that means it can never compile as an app.  Although I'm still not sure how feasible it is to compile apps on-calc.  Have other programmers been able to do it?

All those precompile headers use variables that have to be set somewhere.  That means I would also need preprossesor variables which would be very difficult to add and I'm already running out of memory.  There is no reason that the same program should compile differently on different calculators since only the executable would be distributed ideally.

I've already added it, this is how it works.  You will use the command "Full" found in the modes page and it stands for full speed mode.  However, the command also returns a value.  It will be false (zero) if the calculator does not support 15MHz and true (non-zero) if it does.  So if you had a game you only wanted to be able to run on 15MHz calcs, you can do this:

:!If Full
:Return
:End

That would quit the game if the Full command failed.  If you don't care about the type of calc, then you just use it normally like this:

:Full

The command "Normal" returns to regular speed and doesn't return a value since it can never fail.

Quote from: Quigibo on March 01, 2010, 09:05:53 pm

Actually, I was thinking of changing the single quote to be an ascii character constant like 'A'.  Not sure what will replace it yet, maybe the decimal point since I haven't used it yet and its a single key press instead of [2nd][angle][down][enter]

I like that idea, but does it rule out floating point numbers?

Floats would be prefixed with "Float" so it wouldn't matter, but I don't plan on adding floats until near the end.  Its really an advanced feature.

And Eeems, anything like that I would implement would probably be with the regular if statement.  I Don't think there is any reason to have preprocessor statements since that stuff is taken care of by options in the compiler.  You don't need a preprocessor to handle different headers for instance since they are added automatically by the parser.

While we're on the topic of headers, would you prefer large advanced headers or a simple one.  What I mean by that, is that you can store other information in the header like what shell it should compile to, the name of the output file, some setting to optimize more for speed or size, and other stuff.

But that information doesn't have to be in the source file, you can enter all that data into Axe Parser itself and it will save your settings so you don't have to re-enter that information every time you compile.

I kind of prefer the later since the big headers will just be more to learn and increase source file sizes, but what do you all think about it?

Another thing I was thinking about is maybe instead of a header, you just have to end the program name with a "theta" or something.  This doubles as both a header AND it prevents you from trying to output to a file with the same name.  So if you're making a pacman game, then the source file would be "PACMANθ" and it would compile to "PACMAN" as the output.  You would probably also have the option of naming it something else in case you need 8 letters or something.