DATA 0020H 000BH BIT_ADDR ?BA?XXACT_H BIT 002BH.0 0000H.1 UNIT _BIT_GROUP_ 002BH.1 0000H.7 *** GAP *** IDATA 002CH 000FH UNIT ?ID?XXACT_H 003BH 002DH *** GAP ***
So from what i know Bdata start from 20H and have 16byte of space. I only used 8 bytes in my program however when I want to declare a new bdata
unsigned char bdata test;
the address space overflows.
Checkign the M51 file, it appears that the IDATA is taking up the bdata space??? Is it? Why? How to solve this problem?
"But how come I can't add more bdata varaibles??? "
Because adding bdata pushes up data and idata.
Don't use _at_ unless you need your variable to match up with hardware at a specific location. You are seriously inhibiting the linker from doing it's job. The BDATA variables MUST be located within a very limited part of the '51 memory space since the instructions to perform bit operations are hard-wired.
Then you have a lot of variables that you say must be placed at fixed locations.
What do you think the linker should do if your two separate requests collides with each other? It can't ignore one of your requests, so it is forced to fail.
but there is still space in the first 128byte of internal RAM. Or doesn't the "GAP" in the M51 file means space available?
thanks I got what you saying but I am just wondering because I didn't fix any data in the bdata memory space area, why wouldn't the linker push the data out and allow me to add new bdata? There is enough space in the first 128byte of memory for this "push" procedure to be carried out.
Don't use _at_ unless you need your variable to match up with hardware at a specific location which begs the question: what kind of hardware will ever "match up" with BFATA, DATA, IDATA?
I vcan noit visualize any MMIO except as XDATA. Well, as an oddty, maybe CODE if read only.
So, to the OP get rid of the _at_ they serve no purpose.
also, re 'gaps' the linker takes all variables in a given segment as a block, so if e.g. you have a BDATA at 0x20 and no register bank switches, then, if the smallest block of variables is 0x19, you will have a gap from 0x08 to 0x1f.
Erik
thanks erik, I am still studying on why the original program owner use the _at_ keywords. As of right now I do no see any special purpose or function to it. I removed the _at_ keywords and everything seems to run smoothly(and I hope it stays that way ^^)
so you mean that gap doesn't really mean "free space"? it is actually an area for buffering?
"so you mean that gap doesn't really mean 'free space'?"
Not at all! It certainly is an unused area of memory.
What Erik is saying is that the Linker treats all data from a single module as a group, and it cannot find a group of data that's small enough to fit into the gap - therefore it can't use it.
By fixing some variables at absolute addresses, you leave the Linker only the gaps between them into which it must try to fit all your other variables.
The problem is the same as fragmentation on your PC's hard drive - and is common to many computer storage systems:
en.wikipedia.org/.../Fragmentation_(computer)
As an analogy, consider that you have a load of boxes that you want to fit into a storage area: you know that the total volume of the boxes is less than the total volume of the storage area, but the storage area has some pillars at inconvenient locations. The pillars get in the way, and make it impossible to actually arrange the boxes to fit into the area - even though you know that the volume is sufficient!
Your absolutely-located variables are the "pillars" getting in the Linker's way!
"I am still studying on why the original program owner use the _at_ keywords. As of right now I do no see any special purpose or function to it."
From this, the lesson to learn is the importance of Commenting your code to clearly explain the reason(s) why you do what you do!
GOT IT! thanks once again :) case closed will post if more questions