Can tiny memory model be used with a large stack (at top of memory)?

[tminnich]

 We would like to use the tiny memory model because of its efficiency, but we found a problem with code that makes a copy of a small array. The C compiler transfers the stack pointer  to the H:X register and assumes that H will be zero. The array is not copied correctly when we place the stack at the top of QE128 ram. Is there a way around this, other than using the small memory model and a bunch or NEAR attributes on data definitions?  I have included a pack and go zip of the code stub (targeted for simulation) . The pack and go zip uses a small stack so it works as is.  When the stack is moved to the top of QE128 memory using

STACKTOP 0x207F

in the PRM file, the problem will be re-created.

regards Tom M.

[bigmac · Accepted solution]

Hello Tom,

According to the compiler manual, the tiny memory model requires that both data and stack fit within zero page RAM.  As you have observed, data pointers are assumed to have 8-bit addresses, unless the __far keyword is used.

I cannot see your perceived problem with using the small memory model.  For efficient addressing, you can place the static variables within zero page, using a suitable #pragma preceeding the data definitions.  The use of the __near keyword is not required.

Regards,

Mac

[tminnich]

Mac,

 I do not have much of objection to using the small memory model. Out of curiosity I made small memory model project out of the code example , using the #pragma recommended by your post. I have included the pack and go zip of the small memory model project. The code is a little larger than the tiny memory model, which I kind of expected.

We expected the tiny memory model to support the zero page instructions of the microprocessor best. The tiny memory model seems extremely close to doing every thing we want. In the tiny model code if I added a CLR H assembly language statement at the beginning to my function, my code would work. Also if the stack is moved out of zero page I free up zero page for more variables, and can support a larger stack size (more complicated runtime behavior would be possible).

My coworker wonders if the compiler in small memory model will use zero page (direct addressing) instructions as in the tiny memory model code.

These are just our observations on what turns out to be a rainy day. Thanks for your post.

regards Tom M.

[CompilerGuru]

The compiler does require the stack to be in the zero page for the tiny memory model, the omision of the CLRH is the expected behaviour and there is no configuration to change this in the tiny memory model. The main point of requiring the stack to be in the zero page is that non qualified pointers can safely point to objects on the stack, its less this particular optimization topic that H contains 0 after a TSX.

I would not expect to see to much of a difference to the small memory model if all the globals are allocated in the zero page.

[tminnich]

 It might be good to enforce the rule in the CW IDE that the stack exists in zero page for the tiny memory model (or at least give a warning). I am  going to study up on non qualified pointers. We have a long history in assembly language programming, and this led to the choice of the tiny model. Our discovery of the problems created by moving the stack out of zero page happened late in our software development cycle, we try to avoid such things.

Thanks for your post.

regards Tom M.