salo

Everything included in the patches is there because I needed to give a solution to some problem in order to do development in the pic14 backend. The solution (to each problem) can be the one I propose or another one, but the problem exists and a solution is needed. In order to just fix some bugs, doing what you have done so far is enought. In order to provide some missing functionality (pcall and variadics), applying the experimental patches will do. But in order to continue development (and there...

Hi, Philipp. With respect to the 'long long' support, there is nothing in the pic14 architecture that prevents from implementing it. It is just a matter of extending the current code generation functions that already provide long support, to handle the new data size, and do the same with the initialization code in glue.c. It just requires work-time. But I don't see any reason why this could be of any interest for pic14, neither right now or in the future. With respect to your proposals on what to...

Hi, Philipp. I've been testing the pic14 branch at r11315. Here's what I have found. libsdcc(e).lib are not being built. The reason is a bug in device/lib/pic14/libsdcc/idata.c It must be changed this way: --- a/device/lib/pic14/libsdcc/idata.c +++ b/device/lib/pic14/libsdcc/idata.c @@ -93,6 +93,7 @@ } // while // call main after initialization + (void)main; /* otherwise the _main symbol is not declared */ __asm PAGESEL _main GOTO _main This is one of the bugs I found when testing r11278. Just for...

Hi, Philipp. In a previous post [ https://sourceforge.net/p/sdcc/patches/303/#4ec9/f2d6/1e10/ef39 ] I tried to explain the 'cost' of doing that. Please, Philipp, be so kind to take into consideration that English is not my mother tongue and I'm trying the best I can to be precise and clear and, at the same time, avoid to seem rude or impolite. I see you are dedicating a lot of time to this issue and many other ones related to sdcc, and I really appreciate it. But I feel myself like trying to force...

Hi, Philipp. For your information, I attach my log using gputils 1.5.0, based on r11299.

Hi, Philipp. For your information, I attach my log using gputils 1.5.0, based on r11299.

Hi, Philipp. Confirmed it is related to timeout killing gpsim. It can be fixed this way: --- r11278-svn/support/regression/ports/pic14/spec.mk 2019-06-20 10:32:47.000000000 +0200 +++ r11299/support/regression/ports/pic14/spec.mk 2019-06-25 06:33:23.852623562 +0200 @@ -52,9 +52,9 @@ # run simulator with SIM_TIMEOUT seconds timeout %.out: %$(BINEXT) $(CASES_DIR)/timeout mkdir -p $(dir $@) - -$(CASES_DIR)/timeout $(SIM_TIMEOUT) $(GPSIM) -i -s $< -c $(PORTS_DIR)/pic14/gpsim.cmd > $@ || \ + -$(CASES_DIR)/timeout...

gpsim is not part of gputils. It is another project. At some point in the future I will try to isolate this problem and check it. And all issues related to gpsim will be reported. In any case they will have to be checked with the latests gpsim release, that is coming right now (there is currently a release candidate for 0.31.0). Anyway, I don't see how could this be related to sdcc, although it could be an issue related to fwk/lib/timeout.c A report about what happens in Windows could be useful.