OVERLAY

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

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

"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

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?