OVERLAY

"I don't see any memory usage changes."

Do you mean that they're still overlaid despite your directive, or were they just never overlaid in the first place?

Have you looked at the Application Note about Function Pointers, and searched the knowledgebase? These materials give some more detailed explanations & examples of the overlay mechanism & how to control it.

Isn't true that if I use the OVERLAY directive as below for all of my functions, the linker would put the function's data in separate memory? I am having a problem where the local variables are corrupted even if the function is listed in below

OVERLAY(func0 ! *,func1 ! *,func2 ! *,func3 ! *,func4 ! *,func5 ! *)

Thanks,

Anh

I am having a problem where the local variables are corrupted even if the function is listed in below

Then it sounds like variable overlaying is not the cause of the variable corruption.

IS there anything else in your program that could corrupt your variables?

Jon

I resolved a few corrupted local variables by using OVERLAY. Looks like the OVERLAY does work but I was expecting an increase in memory usage.

Thanks,

Anh

I resolved a few corrupted local variables by using OVERLAY.

Probably not. By using OVERLAY you simply moved the local variables to a different location. The locations that were getting currupted either moved, or there is nothing as critical getting corrupted.

OVERLAY will not fix corruption problems. OVERLAY will only MASK or HIDE corruption problems.


Have you used a program like PC-LINT to check your program?

Jon

My program can be compiled to run on Windows or 8051. It works fine on Windows and I am porting to 8051. There's quite a few function pointers and these pointers are called all over so I think it's impossible (for me) to adjust the calling tree. This is why I want to put some function in it's own memory space rather than adjusting the calling tree. I assume that the way I use the OVERLAY directive would accomplish this but from your suggestions, it doesn't look like it would do this.

Thanks Jon,

Anh

"IS there anything else in your program that could corrupt your variables?"

The 'C' programming language provides a very powerful and effective means to corrupt your variables - the pointer!... ;-)

"It works fine on Windows and I am porting to 8051. There's quite a few function pointers..."

Well, that's very likely (almost certainly?) your problem!

You have read the App Note & Knowledgebase article(s) about this, haven't you?

It is the very nature of the 8051 architecture that makes function pointers a Bad Thing on this processor.

If you really need this code to run on both Windows and 8051, you need to design for the lowest common denominator - and that is certainly the 8051.
Anything an 8051 can do, a Pentium will eat for breakfast - but getting an 8051 to behave like a Pentium is, at best, woefully misguided! :-(

Well, are any of the functions reentrant? If they are, you'll have to use the reentrant keyword. Specifying them without overlay will not avoid data corruption if they are called reentrantly.

Jon

No, there are no reentrant functions.

int func1(const *d)
{
unsigned char *buffer;
}

int func2(unsigned a, struct a **n)
{
char *name;
}

func1 calls func2

Using large model

I found that:
address of buffer: 0x017606
address of name: 0x017608

buffer is generic pointer which should occupy 3 bytes, but linker only allocates 2 bytes.

would OVERLAY(func1 ! *,func2 ! *) fix this?

How can I fix it?

Thanks,

Anh

Why don't you just use NOOVERLAY. That way, none of your programs arguments are overlaid?

Jon

Take a look to the linker map file (*.M51). In the section OVERLAY MAP OF MODULE all calls (as they are seen by the linker) are listed. Is there a call from func1 to func2?

When you write func1 calls func2, how exactly is that call performed? Do you have evidence beyond the equality of addresses that the generated code is actually incorrect?

I think I am giving up with OVERLAY. Lots of manual work that require a lot of time. I like Jon's idea of using NOOVERLAY and it seems to require a few hundred bytes more. I hope NOOVERLAY will give me clean code.

Thanks,

Anh

Still have problems, had to remove all function pointers. Code seems fine now. Thanks everyone,

Anh