Byte Alignment

[G4LCH]

This may seem like a strange question but its not ;-)
Is there any memory / speed advantage with byte aligning the var defs

eg

MyArray Var Word(10)
MyWord Var Word
MyByte Var Byte
MyBit Var Bit

As opposed to
MyByte Var Byte
MyArray Var Word(10)
MyBit Var Bit
MyWord Var Word

In my testing I can see that there is a difference in the memory footprint
and one would guess an increase in speed because at a low level the processor does not need to work so hard??

In other systems that can make quite large speed / memory savings and I just wanted to check that I am not bonkers.

Mark

[Bruce]

This shouldn't make any difference.

    MyArray Var Word(10)
    MyWord Var Word
    MyByte Var Byte
    MyBit Var Bit  
    
' Creates;
    _MyArray   EQU RAM_START + 018h
    _MyWord    EQU RAM_START + 02Ch
    _MyByte    EQU RAM_START + 02Eh
    PB01       EQU RAM_START + 02Fh
    
    MyByte Var Byte
    MyArray Var Word(10)
    MyBit Var Bit
    MyWord Var Word

'  Creates
    _MyArray    EQU RAM_START + 018h
    _MyWord     EQU RAM_START + 02Ch
    _MyByte     EQU RAM_START + 02Eh
    PB01        EQU RAM_START + 02Fh

[Darrel Taylor]

Awwwww! Bruce beats me again.

And he's right. Doesn't make much difference. PBP catagorizes the variables according to type, and then sorts them alphabetically within each type.

The "order" depends on whether you are using a 14-bit or 16-bit core.

For 14-bit cores the order is ...

1 - WORD arrays
2 - BYTE arrays
3 - WORD's
4 - BIT array's
5 - BYTE's
6 - BIT's

For 16-bit cores the order is ...

1 - Bit Arrays
2 - Bit's
3 - WORD's
4 - BYTE's
5 - BYTE Arrays
6 - WORD arrays

A good question might be, Why the difference?

Here's an example of the differences using these variables

Cbyte      VAR BYTE
BBYTEArray VAR BYTE(10)
BwordArray VAR WORD(10)
AWORD      VAR WORD
BWORD      VAR WORD
ABYTEArray VAR BYTE(10)
AbitArray  VAR bit(10)
DWORD      VAR WORD
ABYTE      VAR BYTE
BBYTE      VAR BYTE
AWORDArray VAR WORD(10)
CBit       VAR Bit
BbitArray  VAR bit(10)

Compiled for a 16F877 you get this...

  _AWORDArray    EQU     RAM_START + 018h
  _BwordArray    EQU     RAM_START + 02Ch
  _ABYTEArray    EQU     RAM_START + 040h
  _BBYTEArray    EQU     RAM_START + 04Ah
  _AWORD         EQU     RAM_START + 054h
  _BWORD         EQU     RAM_START + 056h
  _DWORD         EQU     RAM_START + 058h
  PBA01          EQU     RAM_START + 05Ah
  PBA02          EQU     RAM_START + 05Ch
  _ABYTE         EQU     RAM_START + 05Eh
  _BBYTE         EQU     RAM_START + 05Fh
  _Cbyte         EQU     RAM_START + 080h
  PB01           EQU     RAM_START + 081h
     #define _AbitArray               PBA01, 000h
     #define _BbitArray               PBA02, 000h

Compiled for a 18F252 you get this...

  PBA01          EQU     RAM_START + 01Ah
  PBA02          EQU     RAM_START + 01Ch
  PB01           EQU     RAM_START + 01Eh
  _AWORD         EQU     RAM_START + 01Fh
  _BWORD         EQU     RAM_START + 021h
  _DWORD         EQU     RAM_START + 023h
  _ABYTE         EQU     RAM_START + 025h
  _BBYTE         EQU     RAM_START + 026h
  _Cbyte         EQU     RAM_START + 027h
  _ABYTEArray    EQU     RAM_START + 028h
  _BBYTEArray    EQU     RAM_START + 032h
  _AWORDArray    EQU     RAM_START + 03Ch
  _BwordArray    EQU     RAM_START + 050h
     #define _AbitArray               PBA01, 000h
     #define _BbitArray               PBA02, 000h

Interestingly, if you use any BANK modifiers, all that goes out the window.

In fact, once you use a BANK modifier, all variables declared after it will be placed in that BANK and the following banks untill RAM is full, then it goes back to BANK0 and tries to fit things in the remaining space. So even if you only have 1 variable with a BANK2 modifier, you could be placing Lot's of variables in BANK2 and BANK3.

I didn't know that till now.   Thanks for the question Mark!
<br>

[Darrel Taylor]

Well, I'm still in "oh my God, I can't beleive it's doing that" mode.

Taking a random sample of bit's and byte's and array's with random BANK1's ....

Cbyte       VAR BYTE
BBYTEArray  VAR BYTE(10)
BwordArray  VAR WORD(10)
AWORD       VAR WORD
BWORD       VAR WORD
ABYTEArray  VAR BYTE(10)   BANK1
AbitArray   VAR bit(10)
DWORD       VAR WORD
ABYTE       VAR BYTE
BBYTE       VAR BYTE
AWORDArray  VAR WORD(10)
CBit        VAR Bit
BbitArray   VAR bit(10)
C2byte      VAR BYTE      BANK1
B2BYTEArray VAR BYTE(10)  BANK1
B2wordArray VAR WORD(10)
A2WORD      VAR WORD
B2WORD      VAR WORD
A2BYTEArray VAR BYTE(10)  BANK1
A2bitArray  VAR bit(10)
D2WORD      VAR WORD
A2BYTE      VAR BYTE
B2BYTE      VAR BYTE
A2WORDArray VAR WORD(10)
C2Bit       VAR Bit
B2bitArray  VAR bit(10)

When compiled for a 16F877 looks something like this

  _A2WORDArray   EQU     RAM_START + 018h
  _AWORDArray    EQU     RAM_START + 02Ch
  _B2wordArray   EQU     RAM_START + 040h
  _BBYTEArray    EQU     RAM_START + 054h
  _A2WORD        EQU     RAM_START + 05Eh
  _A2BYTEArray   EQU     RAM_START + 080h  <-- BANK1 starts here
  _ABYTEArray    EQU     RAM_START + 08Ah
  _B2BYTEArray   EQU     RAM_START + 094h
  _C2byte        EQU     RAM_START + 09Eh
  _BwordArray    EQU     RAM_START + 09Fh
  _AWORD         EQU     RAM_START + 0B3h
  _B2WORD        EQU     RAM_START + 0B5h
  _BWORD         EQU     RAM_START + 0B7h
  _D2WORD        EQU     RAM_START + 0B9h
  _DWORD         EQU     RAM_START + 0BBh
  PBA01          EQU     RAM_START + 0BDh
  PBA02          EQU     RAM_START + 0BFh
  PBA03          EQU     RAM_START + 0C1h
  PBA04          EQU     RAM_START + 0C3h
  _A2BYTE        EQU     RAM_START + 0C5h
  _ABYTE         EQU     RAM_START + 0C6h
  _B2BYTE        EQU     RAM_START + 0C7h
  _BBYTE         EQU     RAM_START + 0C8h
  _Cbyte         EQU     RAM_START + 0C9h
  PB01           EQU     RAM_START + 0CAh

At this point, I can't see a pattern, or a definate "Rule" that could account for the placements.

A2WORD ends up in BANK0 even though it was declared after 3 BANK1 variables.

AWORD and BWORD were defined prior to any BANK1 vars, and yet, still ends up in BANK1???????

Does anyone see something I'm missing?
<br>

[Melanie]

http://www.picbasic.co.uk/forum/showthread.php?t=545

[G4LCH]

Thanks guys, I did not have a code space problem I just wanted to
check that as I was switching banks that there could be a way to keep
the byte alignment and hence speed.

It come from programming on Mac/PC's where it can make big differences

Thanks for al your input it was great to have more insight, I learnt even more
which is fab and one important thing inspect the ASM file ;-)

Thanks
Mark

[Melanie]

It's not nescessarilly a code-space 'problem'. Sometimes in one sequence, PICBasic squeezes a variable (which just happens to be frequently used) into Bank Zero, and you get a tight code-space compilation. You add a couple of variables later, recompile, and now this variable might no longer be in Bank Zero, but is pushed into Bank 1, and suddenly your program code usage is heaps bigger.

Naturally you jump to the conclusion that shuffling the variables in different sequences varies the code-space used... but it's not the variables themselves, but how they are subsequently accessed that changes the amount of bytes compiled.

So going back to your original thread starter... yes, there IS a speed and memory advantage... the advantage is in getting your most frequently used variables stored into Bank Zero - it makes a BIG difference if you're optimising for performance and code-space.

[G4LCH]

Melanie, thanks for your input in this one and your right
my code does run faster, I moved all of my frequently accessed vars into
bank0 and hypresto its speed is improved.

Thanks again for your valuable input.

Mark