We want to add the capability to not only get the time but also set the time, but there's no "setter" for the "getter" time().
The first ones that come into mind are gettimeofday() and settimeofday(). However, they take a struct timezone argument that doesn't make sense - even the man pages says "The use of the timezone structure is obsolete; the tz argument should normally be specified as NULL." And POSIX says "Applications should use the clock_gettime() function instead of the obsolescent gettimeofday() function."
The ...timeofday() functions work with microseconds while the clock_...time() functions work with nanoseconds. Given that we expect our targets to support only 1/10 of seconds the microseconds look preferable at first sight. However, already microseconds require the cc65 data type 'long' so it's not such a relevant difference to nanoseconds. Additionally clock_getres() seems useful.
In order to avoid code duplication clock_gettime() takes over the role of the actual time getter from _systime(). So time() now calls clock_gettime() instead of _systime().
For some reason beyond my understanding _systime() was mentioned in time.h. _systime() worked exactly like e.g. _sysremove() and those _sys...() functions are all considered internal. The only reason I could see would be a performance gain of bypassing the time() wrapper. However, all known _systime() implementations internally called mktime(). And mktime() is implemented in C using an iterative algorithm so I really can't see what would be left to gain here. From that perspective I decided to just remove _systime().
So far time_t values were interpreted as local time values. However, usually time_t values are to be interpreted as "seconds since 1 Jan 1970 in UTC". Therefore all logic handling time_t values has to be changed.
- So far gmtime() called localtime() with an adjusted time_t, now localtime() calls gmtime() with an adjusted time_t.
- mktime() has to do "the opposite" of localtime(), to keep it that way mktime() does now the inverse adjustment made by localtime().
- All currently present time() implementations internally call mktime() so they don't require individual adjustments.
- Adds new ENOEXEC error code, also used by Apple2 targets.
- Maximum command line length is 40, incl. program name. This is
an XDOS restriction.
- testcode/lib/tinyshell.c has been extended to be able to run
programs.
The constructors are _NOT_ allowed anymore to access the BSS. Rather they must use the DATA segment or the INIT segment. The latter isn't cleared at any point so the constructors may use it to expose values to the main program. However they must make sure to always write the values as they are not pre-initialized.
The way we want to use the INITBSS segment - and especially the fact that it won't have the type bss on all ROM based targets - means that the name INITBSS is misleading. After all INIT is the best name from my perspective as it serves several purposes and therefore needs a rather generic name.
Unfortunately this means that the current INIT segment needs to be renamed too. Looking for a short (ideally 4 letter) name I came up with ONCE as it contains all code (and data) accessed only once during initialization.
Conceptually the INITBSS segment is not initialized in any way. Therefore it makes sense to not load it from disk. However the INIT segment has to be loaded from disk and therefore moved to its run location above the INITBSS segment. The necessary move routine increases runtime RAM usage :-(
Therefore we now "unnecessarily" load the INITBSS segment from disk too meaning that the INIT segment is loaded at its run location. Therefore there's no need for the move routine anymore.
After all we trade disk space for (runtime) RAM space - an easy decision ;-)
Notes:
- The code allowing to re-run a program without re-load present so far could not have worked as far as I can see as it only avoided to re-run the move routine but still tried to re-run the code in the INIT segment that was clobbered by zeroing the BSS. Therefore I removed the code in question altogether. I'm personally not into this "dirty re-run" but if someone wants to add an actually working solution I won't block that.
- INITBSS is intentionally not just merged with the DATA segment as ROM-based targets can't reuse the INIT segment for the BSS and therefore have no reason to place the INIT segment above INITBSS.
- Because ROM-based targets don't copy INITBSS from the ROM (like it is done with the DATA segment) all users of INITBSS _MUST_NOT_ presume INITBSS to be initialized with zeros!
They are smaller and faster because they take advantage of the pce CPU's block-copy instructions.
Also, made a small improvement to the common memmove(), so that it is similar to the pce version.
So far the INIT segment was run from the later heap+stack. Now the INIT segment is run from the later BSS. The background is that so far the INIT segment was pretty small (from $80 to $180 bytes). But upcoming changes will increase the INIT segment in certain scenarios up to ~ $1000 bytes. So programs with very limited heap+stack might just not been able to move the INIT segment to its run location. But moving the INIT segment to the later BSS allows it to occupy the later BSS+heap+stack.
In order to allow that the constructors are _NOT_ allowed anymore to access the BSS. Rather they must use the DATA segment or the new INITBSS segment. The latter isn't cleared at any point so the constructors may use it to expose values to the main program. However they must make sure to always write the values as they are not pre-initialized.
Made other changes that were recommended by Oliver.
* Changed its name from move_init to moveinit.
* Used self-modifying code in the subroutine.
* The INIT segment doesn't need to be optional (it's used by the start-up file).
When a program starts running, INIT is moved from one place to another place. Then, INIT's code is executed; and, the first place is re-used for variables. After the INIT code has finished, the second place can be re-used by the heap and the C stack. That means that initiation code and data won't waste any RAM space after they stop being needed.
