To include the ability to compile C code and have the generated machine code copied over to the simulated code ROM, it will likely be necessary to also copy over the .data (?) sections/segments of the ELF. That way you can just write normal C code and the softcore CPU will be able to use references to variables/read-only data as necessary.
Eventually, this is the form of execution I think should apply to both asm and C code execution. The way I'm generating the binary file for the asm code is quite specialised and relies on us not using any read-only data when running the asm-generated instructions. I think for the future, I would like the .data (?) sections/segments to be copied over to the simulated code ROM, even when generated from asm since this is the normal way of doing it in the real world. Currently, since there's a distinction between the way the code ROM will look depending on whether we generated the machine instructions from C or asm, the debug harness probably needs some way of being told (via the socket connection, perhaps?) which type the machine code is. However, if the generated machine instructions appear alongside a .data (?) section/segment for either way of generating the binary, then the debug harness doesn't need to be told whether it was generated from C or asm and can just happily consume the binary file regardless, as long as it knows where the address of the first instruction is.
To include the ability to compile C code and have the generated machine code copied over to the simulated code ROM, it will likely be necessary to also copy over the
.data(?) sections/segments of the ELF. That way you can just write normal C code and the softcore CPU will be able to use references to variables/read-only data as necessary.Eventually, this is the form of execution I think should apply to both asm and C code execution. The way I'm generating the binary file for the asm code is quite specialised and relies on us not using any read-only data when running the asm-generated instructions. I think for the future, I would like the
.data(?) sections/segments to be copied over to the simulated code ROM, even when generated from asm since this is the normal way of doing it in the real world. Currently, since there's a distinction between the way the code ROM will look depending on whether we generated the machine instructions from C or asm, the debug harness probably needs some way of being told (via the socket connection, perhaps?) which type the machine code is. However, if the generated machine instructions appear alongside a.data(?) section/segment for either way of generating the binary, then the debug harness doesn't need to be told whether it was generated from C or asm and can just happily consume the binary file regardless, as long as it knows where the address of the first instruction is.