-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] boot.s printf data@ is "_heap+4" #48
Comments
Changes to be committed: modified: src/boot.s modified: src/darksocv.ld.src modified: src/darksocv.mem
Thank you for the suggestions! Well, the information at boot is the start address of each segment, but it appears that there is a mistake here and the data segment is in the wrongly location... it says:
Which means that the text segment starts at position 0, the data starts at position 6900 (which is wrong) and the stack starts at position 8192. The free memory is calculated by the stack-heap, which is correct: the stack can down to the heap. Of course, when the stack reaches the heap, the code will probably crash, but it depends of the core that is running. By coincidence, the last variable in the code is the headcheck variable, which is checked all time. Case this variable changes, the code will print an out of memory diagnostic. Well, I made some changes today and it is now far better:
Which means that the text segment starts at position 0 and have 5360 bytes, the data segment starts at 5360 and have 1600 bytes, and the stack segment starts at position 8192 down to the end of data segment, in a way that we have 1232 bytes. Checking the sum of 5360+1600+1240 is exactly 8192! The same code, but with the HARVARD option in the build will result in:
Which means that the text segment starts at position 0 and have 5360 bytes; the data segment starts at 8192 and have 1600 bytes and the stack starts at 16384, all correct, since now we are working with 8KB of ROM and 8KB of RAM. Also, the available memory for stack is 6592 bytes, in a way that 1600+6592 is 8192. Of course, there are some free memory in the ROM memory, but it cannot be used by the stack, as long it is in the instruction bus and the stack requires that the memory is in the data bus. Interesting is that the text and data sizes are the same, which makes sense, since they are only in different positions. |
oh, I forgot the 4 bytes from .sdata... but it is already fixed:
|
Great! darkriscv will be more and more perfect! |
Yes, it's me again!
When I used HARVARD, I get
'boot0: text@0 data@10224 stack@16384 (6160 bytes free)'
.But , actually,data@10228:
0x27f0+4=10228
So I revised it as follows:
But I think text@0 and data@10228 It's also unreasonable:
The text@, You mean the size of text? If so, it should not be 0!
The data@, You mean the size of data? If so, It should be the end address of data minus the start address, Like
10228-0x2000(addr of RAM(0))
!I know, This may be complicated in von Neumann structure. I think it should be like this:
HARVARD:
Neumann:
In addition, if the RAM storage is almost full, stack may cause the program to run incorrectly.
Forgive my attention to detail. : )
The text was updated successfully, but these errors were encountered: