search

commanderx16 / x16-emulator

Emulator for the Commander X16 8-bit computer
383 stars 60 forks source link

Compiled CC65 C PRG does not rerun #438

Open Robbie3 opened 1 year ago

Robbie3 commented 1 year ago

Hi

A simple CC65 (latest Oct 22 version) compiled HelloWorld.C, as mentions by Matt Heffernan in YT video t0jU2MjvCM0 @15:03, does not rerun in the r40 and r41 version of the emulator. instead of rerun, the emulator jumps into a debug mode. load "helloworld.prg" (works) run (works) run (results in debug mode, see attached screenshot)

Rerunning the compiled C PRG works in r38.

kind regards, rob Untitled

irmen commented 1 year ago

This isn't a problem of the emulator. It is how cc65 compiled programs behave. Generally, they don't reinitialize their variables so running them a second time is not going to work.

Robbie3 commented 1 year ago

Hi Irmen Did the PRG behave and run ok in r38? then to my opinion it is an issue with r40 and r41. If i'm mistaken, what C compiler does do the job well?

irmen commented 1 year ago

As far as I'm aware this has never worked well as it is a characteristic of the code generated by cc65. maybe using the --static-locals compiler argument improves things but my knowledge of cc65 is quite limited. I also don't know if the recently released llvm-mos compiler exhibits the same behavior or can be instructed otherwise.

You will likely find better help with this issue by asking it on the Commander X16 forum and/or the Discord - a lot of people in both places there are using CC65.

What I do know is that Prog8 creates explicit circuitry in the outputted PRG to clear/reinitialize all variables at startup, so prog8 programs are able to be re-run multiple times by default. But prog8 is not C

pzembrod commented 1 year ago

@Robbie3: As for other compilers, you might want to try out vbcc. It does have an X16 port though it says in the documentation (section 14.19) that it is a rushed port. In terms of the compiler itself, I would expect vbcc to outperform cc65; at least in terms of supported C features it is quite superior. I don't know and haven't looked at how its runtime lib handles static initialisation.

For it is the runtime library, more than the compiler itself, that determines the restartability that you are asking about. I have encountered the same question when writing the runtime library for cc64. The trade-off is between restartability and available memory: Either you treat the static initialisation data as constant and copy it over to the live location of the static vars. Then your code is restartable and also ROM-compatible. Or you let the live location of the static vars be the same as the location of the static initialisation data. Then you have more memory available as you save the extra memory for the static initialisation data, but your code can't safely restart, and can't be placed in ROM. For cc64 I chose to copy the data, so cc64 binaries can be restarted.