options for allocating static constants

[rlw]

We are using Code Warrior 5.0 for S12X.

We have found that the default allocation of constants into the ROM_VAR seqment applies to static constants as well (that is, constants qualified as static to indicate they are private to the source file they are defined in).

For various reasons, we are using a comples thrisd party library supplied in object form. While we can freely specify the compile options we need, to ask the vendor to make any changes to the actual source code, like inserting #pragma directives to control constant allocation, would incur a $10,000 fee, plus $1000 per day (or fraction there of) for customization services.

I have read through the documentation, but I can't find an option to provide the same control as a #pragma would.

[Lundin]

If it does matter to you at which specific address such static const objects are allocated, the code must already rely on C standard extensions like #pragmas. So I'm not quite sure what the problem is? Why do you need them to be at a specific address?

CW has in addition to #pragma, the non-standard @ operator which allows a variable to be allocated at a given address. I don't think it will solve your problem though, as you would still have to modify the source code.

[rlw]

The problem is that we are running out of fixed page ROM.

With our own code, we have put in #pragma directives to allocate static constants to segments we define. In fact, we have a constant and a code segment for each source file, and, in the linker, we place those pairs of segments so that each pair resides within the same page of ROM (along with as many other pairs will fit). Any non-static coinstants, we allow to default to the ROM_VAR segment.

Unfortunately, we can't simply add #pragma directives to the third party libraries, because they are delivered as objects and the afore mentioned fees. However, we can ask the vendor to compile them with specific options to the compiler. (There is a fee for this, but far smaller.)

I am hoping I have over looked something, but I am unable to find any comp[ile options nor linker directives that can control the placement of object file absent #pragma directives.

[Lundin]

If you move data to banked memory, you will either have to use non-standard far pointers to access it, or inline assembler. Apart from the disadvantages of using non-standard C, you will also have to modify the code. And in addition, far pointers have traditionally been buggy and hard to use in Codewarrior.

The easiest solution by far is to move away as much code as possible from non-banked and put it in banked. Code is far easier than data to move around, you can do so without any program changes. The only code you need in non-banked ROM is ISRs, and perhaps flash programming routines if you have such.

Conveniently you can move code without changes to the source. Just move the DEFAULT_ROM segement in the .prm file to a banked page.Though of course if you have made the design mistake to put ISRs in that segment, you'll have to rewrite the code.

[rlw]

Right now, only ISRs and the constants in ROM_VAR are in fixed page ROM. Everything else is in banked ROM.

Seems the next 2 things try are:

1. Move the ISRs to banked ROM by replacing their fixed page presence with a jump table.

2. Link the third party libraries as a seperate entity, using the MAP file to generate declarations for the variables, constants and functions.

[Lundin]

But how much space would it save to call banked functions from ISR? If the program design is sane, then the total size allocated by all ISRs are just a few hundred bytes. Meaning all 32k are taken by const data? To me, this doesn't make much sense.

[rlw]

A very large portion of those constants are calibrations. We are using the same electronics and software to control different version of the same basic mechanical system. Depending on the feature set for each version, each motor and solonoid can be any of several capacities, like wise the sensor and user controls and indicators vary as well.

Another very large portion is due to our customer's extensive requirements for implementing self-diagnositcs and performance monitoring. There are a lot of conversion and encoding tables required to map the raw signals into the engineering units the customer requires.

[Lundin]

Out of curiousity, why aren't those variables not stored in eeprom? Are you implementing a flash programming routine or do you hardcode the values? In case of the former, such a routine may have to be located in non-banked flash as well.

[kef]

rlw,

Why not just using banked memory model and default constants placement? That would be way more flexible.

What is the benefit of putting some code to this and only this page? Is it some independent code? Then build it as separate application first, move s records to specific page and include in your application. To execute their codes switch PPAGE and jump to starting address. To fix starting address at 0x__8000, make thier codes starting at 0x8003 and put jmp Function_of_interest at 0x8000.

[NavidadRedivivu]

Unfortunatelly there is no such option. I think there were requests before, so I would advice to send a feature request to Freescale. This will not solve your problem on short term obviously. However: you were mentioning that the fee for adding compiler options is much smaller. The compiler has an option which allows prefixing the source file with a header file of choice (-AddIncl if memory serves). So maybe you could go back to your provider and ask for this compiler option giving them a header file including all the pragmas you would like. Something like this:

my_header.h

-------------------

#pragma CONST_SEG MY_CONST_SEG

/* any other pragmas you want */

They shoud compile their libraries with -AddInclmy_header.h and you will get their constants isolated to MY_CONST_SEG, which you can controll at will. Now, it is debatable if what you are doing is code customization or simply adding an option (I vote for 'adding an option' ), but it's worth trying.

[CompilerGuru]

There is no way to automatically allocate static constant's differently than non statics, except place a #pragma CONST_SEG in between them.

When I understand the desired setup correctly, then the idea is to place static constant's into the same bank where all the code of the same compilation unit resides.

While that may be often working, note that it is not safe in general. Some functions could return a pointer to the the static constant across page boundaries, so I would think its a pretty dangerous setup, especially when you cannot review the source code. Also this means that I'm not sure the compiler should be extended to support this.

When looking into ways of archiving this non the less, the main problem I run across is the limitation that ANSI-C does not support to declare static varibles  ("extern static int ddd;" is an error).

I tried shortly, but all the solutions I could come up with are to ugly (call them hack) to show .

- Anyhow I would recommend to try to optimise the non banked constants by some other means.

Maybe the linker option "-cocc" may help to address the constant usage a bit.

- Seldom used constants in your own code could also be allocated into paged memory using far access eventually.

- Externally visible constants (which can be declared!) could be reallocated with something like

// incl.h:#pragma push#pragma CONST_SEG __FAR_SEG MY_CONSTSextern const int sampleConstant @ "MY_CONSTS";#pragma pop

// file.c:#include "incl.h" // ev. via -AddIncl....extern const int sampleConstant = 2;

(technically this also works for static constants, but the compiler issues correctly a warninig for redefining an external as static, that's one of the not so nice hacks I thought of. I'm not recommending hacks . )

Hmm. Actually static arrays can be declared. 

#pragma push#pragma CONST_SEG MY_CONSTSstatic const int array_sample[] @ "MY_CONSTS";#pragma popextern const int array_sample[2] = {2};

Not sure what I should think about this solution at least for arrays. Well anyhow.

Daniel