ASM register management

[Chilly Willy]

Speaking of words versus bytes, there's a quirk in the M68k that I never realized until I thought about it this morning. Suppose I want to deliberately modify only half of a word:

Code: Select all

    move.b #0, d0               ; Overwites LSB
    move.b #0, TwoByteVariable  ; Overwrites MSB!

How counterintuitive! If you always use 16-bit writes, you avoid the problem.

Yeah, I use something like that.

What do you use?

- Kef

Sorry, that was a mis-type - it should read "I'd use", not "I use".

And you hit on the one major advantage of little-endian over big-endian - no matter the size of the int, a pointer always points at the LSB. Some programmers utilitize that without realizing it's different in BE systems. Those programming quirks are REAL hard to find when porting.

[tomaitheous]

I don't think it's quicker, because, looking at the instruction counts, there are no instructions where a word is processed faster than a byte.

I was referring to defining byte type variables in the assembler. Having them in sequence, you're going to hit an address penalty on the odd addressed ones.

[furrykef]

Hmm. I wasn't aware there was such a penalty. Thanks.

[HardWareMan]

I don't think it's quicker, because, looking at the instruction counts, there are no instructions where a word is processed faster than a byte.

I was referring to defining byte type variables in the assembler. Having them in sequence, you're going to hit an address penalty on the odd addressed ones.

If you try access to word or long word at odd address you will get Address Error exception. You can put your Address Error exception handler routine and do something usefull.

[Chilly Willy]

I don't think it's quicker, because, looking at the instruction counts, there are no instructions where a word is processed faster than a byte.

I was referring to defining byte type variables in the assembler. Having them in sequence, you're going to hit an address penalty on the odd addressed ones.

There's no penalty on accessing bytes on odd addresses. I think you meant that if at some point you converted a byte variable into a word or long, you would then run into the odd address violation on the 68000. Just want to make sure people don't get confused and start putting bytes on even addresses thinking it's faster.

[furrykef]

In that case the situation is exactly as I thought it was... so then there would be no sense in which words are faster than bytes.

- Kef

[tomaitheous]

Sorry, I meant accessing them(byte) with a word instruction.

[furrykef]

I'm not sure why you'd want to access a byte using a word access, unless you're operating on multiple bytes at a time, in which case you probably have already aligned the start of the table or whatever anyhow.

- Kef

[tomaitheous]

I'm not sure why you'd want to access a byte using a word access, unless you're operating on multiple bytes at a time, in which case you probably have already aligned the start of the table or whatever anyhow.
- Kef

Using a word base instruction by accident.

[furrykef]

I think if you're using a word instruction with a byte in RAM, you have bigger problems... namely, loading/storing a garbage byte. Not to mention that loading a word from an odd boundary isn't slower, it's flat-out illegal (unless you write an appropriate exception handler as HardWareMan said, but I'd rather just write proper code in the first place).

So I still don't understand what exactly you're getting at...

- Kef

[TmEE co.(TM)]

As long as you're not accessing Words and Longs from odd addresses, you're fine... this gave me some headache, as only Regen emulates Address Error exception (but regen is too slow and a bit buggy to use)...
You can make some use of Address Error exception as HWM said.

[cdoty]

NEVER put anything on the stack if you have a free register. The more you keep stuff in registers, the faster it will be. That's the ENTIRE REASON to do anything in assembly. If you're going to use the stack, you might as well just use C.

NEVER arbitrarily save/restore registers. This goes back to using the stack. If you're going to just push/pop all the registers in every routine, you might as well be using C. You're an ASSEMBLY LANGUAGE programmer - act like it. Use any registers you can, NEVER save/restore unless FORCED to by the need to put something else in a register when no more are free.

NEVER make "prologues" or "epilogues". Again, that goes back to arbitrarily using the stack. Again, if you're going to use them in your functions, might as well be using C.

A lot of this sounds like optimizing too early. I would rather write the routines, and make sure they work. Then, when I need the speed, I'll go back and pick at the routines to remove unused pushing/popping and try to fit data into registers. Granted, I do initially try to get as much into registers as possible. And, we all know that no-one writes the 'perfectly' optimized routine the first time, it takes a few times over to really optimize it.

This is what I did on the CDi (68000), SNES (65816), and FM-Towns (x86) versions of Frog Feast.

A program with several hundred thousand lines is just like one with a few thousand... just longer.

Especially if you manage/organize routines and files correctly.

[Chilly Willy]

I don't think of it as "optimizing", I think of it as "writing in assembly" as opposed to "pretending you're a C compiler".

It's a philosophical difference.

[furrykef]

At the end of the day, only two questions really matter:

1) Is the program free of bugs?
2) Does the program run fast enough to get everything done on every frame?

As long as the answer to both questions is "yes", how you go about programming is irrelevant, really. It doesn't matter if your code is "slow" if you're not dropping frames. So my inclination is to take the approach that is least likely to result in bugs, then optimize if my code is not fast enough -- "make it right, then make it fast."

I have to admit I still don't get this "thinking in assembly" concept. I get the general idea of it but I don't really know how to apply it. Perhaps I need to find some illustrative examples.

- Kef

[Chilly Willy]

"Thinking in assembly" probably comes from lots of work in assembly. C was for mainframes when I first started out. We didn't even have it available - it was assembly or BASIC or Forth or nothing. Eventually, we started to see small-C on 8 bit systems... I can remember when I got Deep Blue C for the Atari and thought "why would anyone use this instead of assembly?"

It's the difference in being fluent in a language and being able to converse in a language, but with a heavy accent.