[BUG] boot.s printf data@ is "_heap+4"

[vgegok]

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:

000027f0 <heapcheck>:
    27f0:   deadbeef            jal t4,fffdddda <io+0x7ffdddda>

0x27f0+4=10228

So I revised it as follows:

_normal_boot:

    la  sp,_stack
    la  gp,_global

    call    banner

    la  a3,_stack
    la  a2,_heap
+   addi    a2,a2,4
    sub a4,a3,a2
    la  a1,_boot
    la  a0,_boot0msg
    call    printf

    call    main

    j   _normal_boot

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:

`'boot0: text@textsize data@datasize stack@_stack (ROM  <LENGTH(ROM)-textsize> bytes free, RAM  <LENGTH(RAM)-daatasize> bytes free)'`

Neumann：

`'boot0: text@textsize data@datasize stack@_stack (MEM <stack-textsize-datasize> bytes free)'`

In addition, if the RAM storage is almost full, stack may cause the program to run incorrectly.

Forgive my attention to detail. : )

[samsoniuk]

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:

boot0: text@0 data@6900 stack@8192 (1292 bytes free)

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:

boot0: text@0+5360 data@5360+1600 stack@8192 (1232 bytes free)

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:

boot0: text@0+5360 data@8192+1600 stack@16384 (6592 bytes free)

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.

[samsoniuk]

oh, I forgot the 4 bytes from .sdata... but it is already fixed:

 .bss           0x0000000000001b30        0x0 boot.o
 *(.sdata)
 .sdata         0x0000000000001b30        0x4 main.o
                0x0000000000001b30                heapcheck
                0x0000000000001b34                _edata = .
                0x0000000000002000                PROVIDE (_stack = (ORIGIN (MEM) + LENGTH (MEM)))

boot0: text@0+5360 data@5360+1604 stack@8192 (1228 bytes free)

[vgegok]

Great! darkriscv will be more and more perfect!