Assembly 'area'

[markm]

I have a few questions about the assembler 'area' command. Basically I should be able to do the following:

area bss(ram) -- for the RAM variables
area text(rom, rel) -- for the code

and then let the PSoC development environment manage the rest, correct? Or is there some advantage to having different areas?

How do I control the size of the stack? Is there a default stack size?

I assume the stack starts at 0x00 and grows up. Should I 'org' the bss to do this? Since they share the same RAM space.

Do I want to let the assembler do "code compression", or is it automatic? Do I need to use .literal/.endliteral to protect data tables?

Why would I want to use .section/.endsection? Is it similar to '#if 0 #endif' to conditionally compiled code?

[jmmilner]

I have a few questions about the assembler 'area' command. Basically I should be able to do the following:

area bss(ram) -- for the RAM variables
area text(rom, rel) -- for the code

and then let the PSoC development environment manage the rest, correct? Or is there some advantage to having different areas?

I'd stick with this until you get to the point where you have multiple loadable configurations of analog and digital blocks. Then you can get fancy and use the abs to force data or code to a fixed address or the ovr option to share RAM across mutually exclusive data groups.

How do I control the size of the stack? Is there a default stack size?

Control of the size of the stack depends on careful design of your application. There is no hardware support for limiting the stack size, nor is there a default stack size.

I assume the stack starts at 0x00 and grows up. Should I 'org' the bss to do this? Since they share the same RAM space.

The stack starts at _stack_start, which is managed by the loader. The boot.asm code generated by PD sets up SP for you prior to calling _main, which is assumed to be the entry point for your code. The stack does grow upward and can overwrite the SSC control block before wrapping around to zero.

Do I want to let the assembler do "code compression", or is it automatic? Do I need to use .literal/.endliteral to protect data tables?

Actually code compression is done on the fully resolved binary the loader produces - duplicate sequences in the 'text' area are assumed to be repeated instruction sequences and are compressed by making a subroutine of the sequence and calling it. Read-only data tables, as well as string literals, need to be flagged as 'non-code' via the .literal/.endliteral directives to avoid being compressed. I'd suggest using the .literal/.endliteral directives but not turning code compression on - it is more trouble than it is worth to me.

Why would I want to use .section/.endsection? Is it similar to '#if 0 #endif' to conditionally compiled code?

These directives are used to bracket a code sequence that can be removed if the global label in the code sequence isn't referred to when the code is linked. The intended use is to minimize library code being loaded when not used. The assembler has if, else, and endif directives for conditional assembly. Look at boot.asm for examples of how this is used.

[markm]

Control of the size of the stack depends on careful design of your application. There is no hardware support for limiting the stack size, nor is there a default stack size.

Quote:
I assume the stack starts at 0x00 and grows up. Should I 'org' the bss to do this? Since they share the same RAM space.

The stack starts at _stack_start, which is managed by the loader. The boot.asm code generated by PD sets up SP for you prior to calling _main, which is assumed to be the entry point for your code. The stack does grow upward and can overwrite the SSC control block before wrapping around to zero.

I saw _stack_start in the boot.asm source, but I could not find where it is defined. I assumed it follows bss and the RAM used by the analog and digital blocks.

So, I shouldn't worry about the stack bumping into the bss area or vice-versa? In the 256 bytes RAM that these parts have, based on your experience, how big a stack size should there be? 20 bytes, 32 bytes, obviously the complexity of call nesting, interrupts and push/pop operations need to be factored in as well as the RAM required by the various digital and analog blocks. So do you think the following "formula" is valid:

256 = Bsize + Vsize + Ssize

where Bsize is the analog and digital blocks allocation of ram
Vsize is the application variables
Ssize is the stack size.

Assuming that the Bsize = 30 and the SSize is 32 then we can have 194 bytes used for variable storage or do you think the stack needs to be bigger?

[jmmilner]

So do you think the following "formula" is valid:

256 = Bsize + Vsize + Ssize

where Bsize is the analog and digital blocks allocation of ram
Vsize is the application variables
Ssize is the stack size.

Would that it were that simple! There are at least 3 additional factors that need to be considered. First, if you use any C code, the compiler will allocate up to 15 bytes of 'virtual registers', starting at address 0. Second, the top 8 bytes of RAM, starting at address 0xF8, are reserved for Supervisory ROM function variables. These are used to pass and return values for the SSC instruction, which provides access to functions like flash block read/erase/write. These are the basis for some UMs, such as the EEPROM. The third factor is interrupts, which use the same stack as your application. At a bare minimum this will require 3 bytes and can be much more, especially if you use C for ISR code, where the whole set of virtual registers might be stacked (15 bytes). Summing up, best case is 11 bytes, worst case is at least 41, and typical is somewhere between, assuming you don't allow nested interrupts.

[markm]

I am not planning on interfacing C with this project. But it sounds like I shouldn't do any 'org'-ing. I should just put my variables in bss and my code in text,rel with the .literal/.endliteral protecting data and jump tables.

Hopefully, I won't need more than half the RAM for my variables and everything should be peachy.

[markm]

It's a day later and I am a touch bit wiser about these assembly stack things. After studying the .mp output file (map file), I found that the stack is set to be 16 bytes long. This value is controlled by a file called stackzone.asm which is buried in the 'tools' subdirectory of the Cypress PSoC developer software. Here is the complete stackzone.asm file:

Code: Select all

; The object from this source file is linked last
; to ensure that it comes after any user defined
; RAM areas. You can build any changes made to this
; file by typing "iasm8c stackzone.asm" at a command
; console.

area Stack_Zone(ram,rel,con)
export _stack_start
_stack_start::
   blkb 16

; You can change the size of of the ram block
; for your stack size expectations.  The linker
; will complain if there is not enough room for
; your expected stack size.

You would change that 16 to what ever number you want, you may even go down if you are hurting on ram space for variables.

[todd]

I wonder if stackwalk interests you.