This is not an Axe topic. This is an ASM topic.

SafeRAM are areas that all ASM programs case use as scratch space to store temporary variables, matrices, and such things. Doors CS names six areas of SafeRAM for programs to use, for example.

I'm unsure what you mean, but using SafeRAM is fine, as long as you can make sure that different chunks of it are being used correctly between modules of your program. i.e., don't use the first byte of SaveSScreen for storing a variable, if another part of the program will use that byte for some temporary value; it'll destroy whatever was already in that location as the long-life variable.

What I'm trying to ask is what would happen in the following situation:

User 1 writes a useful routine that utilizes AppBackUpScreen through AppBackUpScreen+17

User 2 uses user 1's routine in a program of theirs and calls that routine from their program.

What's the likelihood that User 2 will have variables stored in AppBackUpScreen? Is using SafeRAM a practice usually avoided by asm coders in case a function they call that they didn't write changes the data in the SafeRAM?
does the TI-OS have some sort of allocation table for SafeRAM?

Your program can guarantee that SafeRAM's contents are safe as long as it is running. Once it quits, those contents are no longer safe at all, since some other program might have used the safeRAM for anything. If you need long-term storage that you can make sure will stay the same between the program being run multiple times, you'd use bytes within the program itself, and let Doors CS do writeback.

I thought it might be just as easy as that: if you don't want your variables to be tampered with, don't stick them willy-nilly in SafeRAM and then call a function authored by somebody without checking to see what SafeRAM it modifies.

Wow I'm dumb.

Basically, that covers it. All Doors CS routines, for example, are guaranteed not to touch SafeRAM unless they're explicitly documented not to. SafeRAM is generally quite safe, in my experience.

When using a stack in z80, is it considered an acceptable technique to move the stack pointer to access the data below the surface of the stack without using pop or push as long as your replace the sp at the top of the stack later? I mean, if you need to keep track of more than 7 8-bit pieces of data at once, you can't do that by using only registers, and whenever you do a pop, you lose one piece of data.

for instance:

Code:

Generally, you should avoid using the stack to hold your inputs unless you have a really good reason. Axe only uses this to create "register independence" to simplify parsing, but it can sometimes cause larger code sizes when all the inputs are trivial expressions.

You do have more space than just 7 8-bit registers. First of all, there are shadow registers, so you can double that number by using af', bc', de', and hl'. However, these have their own complications. Another commonly used input is the app flags to hold Boolean values. There are a lot of these available. Finally, if you have a routine with that many inputs, you are likely over-generalizing. You can often get more efficient code by splitting your routine into different "versions" to remove the version argument (such as different methods for sprite logic).

And as always, if the things you are keeping track of are values that are going to be kept around longer than a call to the subroutine, you should be storing those values in free ram somewhere instead of trying to cram everything into registers.

I think you're misunderstanding my question. I'm not trying to use the stack to hold inputs, I'm using the stack to hold the data that I acquire as a result of different calculations that I will have to use later in my routine. They are not only boolean values, and if I tried to toggle the app flags like that to hold 8-bit values, my code would swell to the size of a bloated hippopotamus. Moreover, I don't really want to use di, ei, and the shadow registers, I want to keep interrupts enabled during my routine, and I think that ex and exx wouldn't suit my needs.

I just want to know if it's considered acceptable to use instructions like inc sp and ex (sp), hl. That's all I want to know.

Anything is considered "acceptable" if it works "inc sp" will not have any side effects assuming you consider the stuff you're skipping over deleted. "dec sp" however can be tragic should an interrupt occur between the operations because it will erase the values you are trying to get from the stack. This can be avoided though by doing the decreasing with hl and then performing "ld sp,hl" right after.

But anyway, I still recommend my previous suggestion:

Since you need the values after the subroutine is done, this sounds like it would be more efficient in RAM.

thanks, quigibo! That answers my question , but I must be really bad at explaining things... all of the data in my imaginary subroutine is useless after the subroutine is over, it's a graphics subroutine and after I draw my stuff, I don't care what data gets sent on.
The inc/dec sp and ex (sp), reg16 is only for accessing data that the subroutine calculated internally and then needs later.

One thing you should be very careful about is that interrupts don't fire and bcall()s don't occur while you have the stack moved around; otherwise you might find some very unexpected failures occuring.

Thanks for the advice on that, Kerm, I would have totally forgotten about that!

Well, does that mean it's clumsy and bad practice to use the sp like I'm suggesting?

Is there a good tutorial out there about stacks and how to efficiently operate them?

While I was working on my addition function for floating point numbers, I found myself accessing nibbles on a very regular basis. The code that I used to do so usually went something like this:

Code:


I feel like there should be a faster/more compact/less clunky method than this. What is the standard in the community for accessing nibbles? What do you all do to access nibbles?
Thanks!

Bitmasking and shifting is indeed the way to go if you need the nibbles each aligned at the low end of a byte. If you're clever, though, you can often find ways to process two nibbles at a time, in my experience.

Thanks for the suggestion, Kerm! the thought of doing this had passed through my mind, but I wasn't sure if it was worth trying, so I just copped out and did it the easy way. When I get the chance I'll go back and rewrite my addition function. YAY OPTIMIZATION!!