SX/B RAM Banking Scheme

RonW · 2006-09-25 21:29

I have an SX/B project that has filled up the SX-28 program memory, so I need to optimize. Because of the number of variables I needed, I had to create several arrays. Variables in these arrays have to be accessed indirectly and this has contributed quite a few words to the program size. I've come up with a scheme to eliminate much of this indirect addressing and I wanted to run it by the group. Here it is:

1. Group all (or substantially all) the variables for a code segment, such as a subroutine, into an array, such as:

sub1Data VAR BYTE(16)

2. Create "aliases" for these variables as byte or word variables addressed in Bank 0, addresses $10-1F. For example, define a new variable such as sub1Byte0 at address $10 to correspond to the real data at sub1Data(0). Repeat this for each element of the sub1Data array. These "alias" variables can be defined using SX/B declarations by paying careful attention to aliasing and order of appearance in the source code.

3. At the beginning of the code segment add the SX/B directive:

BANK sub1Data

and at the end of the segment add the directive:

BANK 0

4. Within this code segment, refer to the sub1Data variables by their Bank 0 alisases. Commands will compile with direct addressing and will reference the correct sub1Data addresses. RAM addresses $10-1F cannot be accessed within the code segement without inserting additional BANK directives. Care must be taken to ensure that execution flow does not enter the segment without executing the BANK sub1Data instruction and does not exit the segment without executing the BANK 0 instruction.

Does anyone see a problem with this? Can anyone suggest a better approach?

Thanks.

Bean · 2006-09-25 23:08

Ron,
You got the idea. That is how it's done.

If you can switch to SX48, it has twice as much code space. You might not have to use tricks like that.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com

There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
·

RonW · 2006-09-25 23:20

Thanks. This scheme brought to mind a possible change to the BANK directive, or maybe a new directive...

Following a BANK defaultbank directive, the compiler could use direct addressing to access varibles in defaultbank and use indirect addressing only for variables not in defaultbank. I think this is possible as long as arrays don't cross bank boundaries.

Also, it would be convenient to be able to define variables (including words) above bank 0 without using arrays and aliases.

I think these two changes would make it easier and more efficient to utilize all the available RAM.

Is there enough interest in something like this to make it worthwile?

Bean · 2006-09-26 00:10

RonW said...
Following a BANK defaultbank directive, the compiler could use direct addressing to access varibles in defaultbank and use indirect addressing only for variables not in defaultbank. I think this is possible as long as arrays don't cross bank boundaries.

Ron,
· That would be a major undertaking. To be honest, I think you are using SX/B in ways 99% of user would never attempt. I think an easier way would be ... (see below)

RonW said...
Also, it would be convenient to be able to define variables (including words) above bank 0 without using arrays and aliases.

· Now that would not be too hard. I'm thinking something like:

  array1 VAR Byte(16)
  varA   VAR array1(0) ' This is a normal aliases array element
  varB   VAR Byte @ $30 ' SX/B will generate code for a "normal" (non-array) variable
  varC   VAR Byte @ array1(0) ' SX/B will generate code for a "normal" (non-array) variable

Now the element array1(0) can be aliased as regular array element [noparse][[/noparse]varA] or as a regular byte variable [noparse][[/noparse]varB or varC]. Of course it would be up to the programmer to make sure the BANK is set properly before using [noparse][[/noparse]varB or varC]. As in...

BANK array1
varB = 5 ' Generates MOV varB,#5
varC = 100 ' Generates MOV varC,#100
BANK

Note that BANK without any parameters will restore the default bank on both the SX28 & SX48 properly.

Could you live with that ?

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com

There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
·

RonW · 2006-09-26 02:10

I like your suggestion. I would also like to see...

varD VAR WORD @ $30

From your example, it looks like you're also saying that variables defined with the new "@" parameter would be treated differently by the compiler, i.e. they would always be accessed using direct addressing. So, as you said, the programmer would have to be sure BANK is set. Do I understand that correctly?

That might be confusing. I think the assumption might be that adding @ $30 to a variable declaration is simply forcing it to a specific RAM address. There would still be the expectation that the compiler would handle the BANK transparently.

It might be clearer if you used an extension to the variable name, such as _REG, to refer to the 5-bit register portion of the address. Something like this maybe...

BANK array1
varB_REG = 5 ' Generates MOV varB,#5 [noparse][[/noparse]without regard to the current value of BANK]
varC = 100 ' Generates MOV FSR,#varC; MOV IND, #100; BANK array1 [noparse][[/noparse]just like it does now - regardless of BANK]
BANK

This gives the programmer the option of declaring variables anywhere in RAM without worrying about BANKing. And it also gives him the option of reducing execution time and code space if he needs to. This form would remind the programmer to keep up with BANKing when he sees the _REG.

If all the additional symbols this would add is a problem, you coulrd require an explicit form of the declaration to create the _REG. Maybe...

varC BYTE @$30 REG 'defines varC at address $30 and creates a symbol varC_REG

How does that sound?

Bean · 2006-09-26 02:21

RonW said...
I like your suggestion. I would also like to see...

varD VAR WORD @ $30

Yep, Okay, WORD variables too.

RonW said...
From your example, it looks like you're also saying that variables defined with the new "@" parameter would be treated differently by the compiler, i.e. they would always be accessed using direct addressing. So, as you said, the programmer would have to be sure BANK is set. Do I understand that correctly?

Yes, you understand what I'm getting at.

RonW said...It might be clearer if you used an extension to the variable name, such as _REG, to refer to the 5-bit register portion of the address. Something like this maybe...

BANK array1
varB_REG = 5 ' Generates MOV varB,#5 [noparse][[/noparse]without regard to the current value of BANK]
varC = 100 ' Generates MOV FSR,#varC; MOV IND, #100; BANK array1 [noparse][[/noparse]just like it does now - regardless of BANK]
BANK

This gives the programmer the option of declaring variables anywhere in RAM without worrying about BANKing. And it also gives him the option of reducing execution time and code space if he needs to. This form would remind the programmer to keep up with BANKing when he sees the _REG.

If all the additional symbols this would add is a problem, you coulrd require an explicit form of the declaration to create the _REG. Maybe...

varC BYTE @$30 REG 'defines varC at address $30 and creates a symbol varC_REG

How does that sound?

Hmmm, I'll have to think about how that will impact the compiler. It's an interesting idea though...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com

There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
·

SX/B RAM Banking Scheme

Comments