SNES register sizing schemes (65816 M and X)

[Sik]

On the Mega Drive I use both 8-bit and 16-bit often (32-bit rarely), honestly it'd strike me as odd if on the SNES you wouldn't be making much use of both sizes either.

[Stef]

For general logic I'm using 16 bits about 80% of time then 10% of 8 bits and 10% of 32 bits but definitely the 68000 architecture tend to bias for 16 bits size use. When i really need to optimize my code for large and heavy processing then i almost exclusively use 32 bits, it definitely gives a nice advantage over 16 bit operations.
For the SNES honestly i don't see how 8 bits indexing can be useful so i would stand up with 16 bits index registers at least. Then for accumulator i would use 16 bits almost time except in critical parts where 8 bits can bring a speed advantage.

[Sik]

definitely the 68000 architecture tend to bias for 16 bits size use.

But 8-bit operations rarely have a penalty (・ω・`) (for data that naturally fits a byte, that is)

Then for accumulator i would use 16 bits almost time except in critical parts where 8 bits can bring a speed advantage.

Normally what you'd get from 8-bit values is a memory advantage instead (i.e. taking up less space in RAM, especially if it's something in a list of values).

[Bregalad]

This makes no sense to me.

What makes no sense ?

1) Does the words I've written make no sense
2) Does the concept of not wanting to ever change register sizes makes no sense
3) Does the concept that I wrote about make no sense (i.e. there is plenty reasons to have a 8-bit accumulator with 16-bit index and stick with it)

In all cases as I said I never did real 65c816 coding (I only modified existing SNES demoes for fun) so I can't really juge. But I think it'd make sense to never change reigster sizes in order to avoid risks of accidental crashes and simplify the ABI.

Normally what you'd get from 8-bit values is a memory advantage instead (i.e. taking up less space in RAM, especially if it's something in a list of values).

Yes, arrays of 8-bit values are definitely an usage of a 8-bit accumulator, but it can also be acheived with 16-bit accumulator and AND/OR operations. Yes that's probably penalty in all aspects (speed and ROM size) but what I mean is that acessing a 8-bit array with a 16-bit accumulator should be possible, even if it's not the most efficient way. I can see how in some contexts (where optimisation is not required) you'd rather bother with AND/OR operations rather than messing with SEP/REP.

[93143]

Normally what you'd get from 8-bit values is a memory advantage instead (i.e. taking up less space in RAM, especially if it's something in a list of values).

But 8-bit operations are slightly faster on SNES. The extreme case, an immediate load, is 50% slower in 16-bit mode, and direct-page RMW instructions in FastROM are a close second. Not to mention that most of the MMIO registers are 8-bit - even some registers that take 16-bit values, like the scroll offsets and the Mode 7 matrix elements, are mapped to one byte and take half-values in sequence.

What makes no sense ?

I (and apparently several others) see value in having 16-bit X/Y and 8-bit A sometimes, mostly changing A as desired. Your statement seems to be a declaration that we're all wrong, and that there can be no good reason to ever change that setup once it's been arrived at - with no rationale given, implying that it should be obvious. The lack of evident rationale is the reason I said it made no sense to me.

But I think it'd make sense to never change reigster sizes in order to avoid risks of accidental crashes and simplify the ABI.

Maybe, but it seems like it could be harder to code that way than to just keep track of register size, even if you don't care about speed.

The confusion is somewhat mitigated by the fact that it takes 3 cycles to switch register size, so if you're coding for speed there's often a minimum size of code chunk below which it isn't worth it to switch, and it's advantageous to group operations that require a certain setup. And since it's evidently rare to need 8-bit index registers, you mostly only have to keep track of the accumulator. If you're using a lot of immediate values, they can be a handy visual cue, though they're no substitute for proper comments...

I don't think I've ever had a crash due to wrong register size, though I did have a bug once that was caused by a failure to push B to the stack. I have more trouble with $ and #...

[AWJ]

This makes no sense to me.

What makes no sense ?

1) Does the words I've written make no sense
2) Does the concept of not wanting to ever change register sizes makes no sense
3) Does the concept that I wrote about make no sense (i.e. there is plenty reasons to have a 8-bit accumulator with 16-bit index and stick with it)

In all cases as I said I never did real 65c816 coding (I only modified existing SNES demoes for fun) so I can't really juge. But I think it'd make sense to never change reigster sizes in order to avoid risks of accidental crashes and simplify the ABI.

Normally what you'd get from 8-bit values is a memory advantage instead (i.e. taking up less space in RAM, especially if it's something in a list of values).

Yes, arrays of 8-bit values are definitely an usage of a 8-bit accumulator, but it can also be acheived with 16-bit accumulator and AND/OR operations. Yes that's probably penalty in all aspects (speed and ROM size) but what I mean is that acessing a 8-bit array with a 16-bit accumulator should be possible, even if it's not the most efficient way. I can see how in some contexts (where optimisation is not required) you'd rather bother with AND/OR operations rather than messing with SEP/REP.

From an extremely cursory inspection I did of Gradius III once, it did appear to use 16-bit accumulator just about everywhere. That's probably one of the reasons the game is slow; another that I noticed was that nearly every JSR was 24-bit.

[Sik]

Yes, arrays of 8-bit values are definitely an usage of a 8-bit accumulator, but it can also be acheived with 16-bit accumulator and AND/OR operations. Yes that's probably penalty in all aspects (speed and ROM size) but what I mean is that acessing a 8-bit array with a 16-bit accumulator should be possible, even if it's not the most efficient way. I can see how in some contexts (where optimisation is not required) you'd rather bother with AND/OR operations rather than messing with SEP/REP.

Wouldn't that make the code more complex to understand than just toggling the size flag?

Also for the record, I wasn't thinking about just arrays of 8-bit values. The entry of the list of objects in a level may be another good example, since in each entry some values will be 16-bit (like the coordinates) but some others probably can be just 8-bit (e.g. angle or health).

[psycopathicteen]

This makes no sense to me.

What makes no sense ?

1) Does the words I've written make no sense
2) Does the concept of not wanting to ever change register sizes makes no sense
3) Does the concept that I wrote about make no sense (i.e. there is plenty reasons to have a 8-bit accumulator with 16-bit index and stick with it)

In all cases as I said I never did real 65c816 coding (I only modified existing SNES demoes for fun) so I can't really juge. But I think it'd make sense to never change reigster sizes in order to avoid risks of accidental crashes and simplify the ABI.

Normally what you'd get from 8-bit values is a memory advantage instead (i.e. taking up less space in RAM, especially if it's something in a list of values).

Yes, arrays of 8-bit values are definitely an usage of a 8-bit accumulator, but it can also be acheived with 16-bit accumulator and AND/OR operations. Yes that's probably penalty in all aspects (speed and ROM size) but what I mean is that acessing a 8-bit array with a 16-bit accumulator should be possible, even if it's not the most efficient way. I can see how in some contexts (where optimisation is not required) you'd rather bother with AND/OR operations rather than messing with SEP/REP.

From an extremely cursory inspection I did of Gradius III once, it did appear to use 16-bit accumulator just about everywhere. That's probably one of the reasons the game is slow; another that I noticed was that nearly every JSR was 24-bit.

Super Castlevania 4 is also like that, but I think the main thing that bogs SC4 down is the fact it never uses the direct page register at all.

[Stef]

definitely the 68000 architecture tend to bias for 16 bits size use.

But 8-bit operations rarely have a penalty (・ω・`) (for data that naturally fits a byte, that is)

But are not any faster as well... and if you use a 8 bit value as an index later then it will be slower.
And when you use C it even worst because of the calling convention, 16 bits generally work better

Normally what you'd get from 8-bit values is a memory advantage instead (i.e. taking up less space in RAM, especially if it's something in a list of values).

Memory is *never* a problem for me on MD as on SNES, you have plenty of them so there is no interest in trying to optimize their use. It is definitely useful on NES and PCE systems though :p

[Khaz]

Personally I've been working on the assumption that processing time is too precious to program with "avoiding crashes" as a priority, at least when it comes to register sizes. When I make a rep/sep mistake, I almost always find out immediately. And it's really not that hard to keep track of. I php/plp around almost every subroutine so far just to be safe. It's such a tiny investment to include those instructions and it gives so much freedom. When a routine is small and frequently-called enough that php/plp would start wasting real time, it's simple enough to follow that I don't need it to begin with.

[tepples]

But are not any faster as well... and if you use a 8 bit value as an index later then it will be slower.
And when you use C it even worst because of the calling convention, 16 bits generally work better

Is there even a free 65816 C compiler? The only free C compiler for 6502 family that I know of is cc65, and that supports only 8-bit.

Memory is *never* a problem for me on MD as on SNES, you have plenty of them so there is no interest in trying to optimize their use. It is definitely useful on NES and PCE systems though :p

On Genesis, the more you fit in $FF8000-$FFFFFF, the more you can use short addresses. On Super NES, the more you fit in $7E0000-$7E1FFF, the more you can use direct page addresses.

[Sik]

But are not any faster as well... and if you use a 8 bit value as an index later then it will be slower.
And when you use C it even worst because of the calling convention, 16 bits generally work better

Is there even a free 65816 C compiler? The only free C compiler for 6502 family that I know of is cc65, and that supports only 8-bit.

He was talking about 68000 =P (which makes it even worse actually because both the compiler and the ABI prefer 32-bit and will end up casting everything to 32-bit as a result - some compilers use 16-bit int, but dunno what ABI they use in that case)

[TOUKO]

Memory is *never* a problem for me on MD as on SNES, you have plenty of them so there is no interest in trying to optimize their use. It is definitely useful on NES and PCE systems though :p

Working with 8 bit allow you to do some tricks that are not possible with 16 bit .
Of course on 68k, working with 8 bit variables have no interest because is not faster than 16,and i think you cannot work with the MSB of a 16 bit value .

And like sik, i use more 8 bit than 16, 16 bits are usualy for pointers, 32 bit is useless for me .

[psycopathicteen]

I can't believe REP and SEP take 3 cycles, when I always thought it took 2.