RE: RISC-V: Stack pointer initialization in crt0

I would say there are a couple of options. The stack pointer initialization must be optional, e.g. sp should not be overridden when starting a user application on top of an OS
This document gives some good inspiration:
https://developer.arm.com/documentation/dui0475/m/the-arm-c-and-c---libraries/stack-and-heap-memory-allocation-and-the-arm-c-and-c---libraries/stack-pointer-initialization-and-heap-bounds

I do like solutions where you can compile things without the need for extra assembly or linker files. So maybe keeping it simple and adding a macro for the stack start could be something.

mstatus and such can be handled later. My point is just to make the startup function self-sufficient. I.e. as it is using sp, there should be a way to initialize it.

> -----Original Message-----
> From: Kito Cheng <[email protected]>
> Sent: Friday, 3 January 2025 06:55
> To: Christian Herber <[email protected]>
> Cc: [email protected]
> Subject: Re: RISC-V: Stack pointer initialization in crt0
> 
> So the question becomes: what should the sp be initialized to?
> __stack_pointer$? the end of the data section? Or another random address?
> 
> This crt0.S is indeed missing some essential initializations, like `mstatus` and
> various other CSRs. But, just like Jim Wilson’s view back then, I also prefer
> leaving this to the BSP to handle.
> 
> On Thu, Jan 2, 2025 at 10:01 PM Christian Herber
> <[email protected]> wrote:
> >
> > Newlib works great when building a linux user space executable.
> >
> > However, if you want to run something baremetal in M-mode, the standard
> startup is a roadblock because of the lack of stack pointer initialization.
> >
> >
> >
> > I see there had been discussion on this topic here:
> > https://github.com/riscvarchive/riscv-newlib/issues/39
> >
> >
> >
> > I dislike the current situation as it puts an unnecessary obstacle for users e.g.
> switching from Arm to RISC-V.
> >
> > As a user, especially if I build with -spec=nosys.spec, it is strange if the
> startup assumes an operating system has initialized the stack pointer.
> >
> >
> >
> > This recent reddit thread shows the situation quite well:
> >
> https://www.reddit.com/r/RISCV/comments/1hjbxyd/running_an_mmode_r
> v32_
> > cprogram_on_qemu/