- 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.
* Added an important ".code" directive.
* Import a linker-created zero-page symbol as an absolute address; then, convert it to zero-page when it is used.
Fixes bug report #198.
That parameter's type is unsigned; but, the functions return an int. If the size is too big for a signed integer, then return an error code.
If the size is zero, then don't write anything into a buffer (the buffer pointer may be NULL). But, do format and count the arguments.
A description of positions [left, right] is appropriate more for C code than for Assembly code. (A description of timing [first argument, second argument] is more appropriate for the way that Assembly code is written.)
The cc65 doc explicitly states that the return value of _heapmaxavail() can be used as parameter of malloc(). To actually allow for that the size of HEAP_ADMIN_SPACE has to be substracted from the raw size of the largest free heap block.
- No complex shell logic.
- "Source file shadowing" for all targets via vpath.
- Dependency handling.
- True incremental build.
- Don't write into source directories.
- Easy cleanup by just removing 'wrk'.
that call C code, we don't need to save the register bank, because the C code
will save it, when needed.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5909 b7a2c559-68d2-44c3-8de9-860c34a00d81
are closed on exit, so atexit handlers may close the files themselves or
whatever is necessary for a clean shutdown.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4939 b7a2c559-68d2-44c3-8de9-860c34a00d81
originally written by Henry Spencer and supplied by Harald Arnesen.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4737 b7a2c559-68d2-44c3-8de9-860c34a00d81
__directerrno and moved both to errno.s. Changed several sources to use these
functions. Needs testing.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4718 b7a2c559-68d2-44c3-8de9-860c34a00d81
return -1 in case of an invalid argument, which it didn't until now.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4698 b7a2c559-68d2-44c3-8de9-860c34a00d81
more than one version of ca65 is installed on the machine (Spiro Trikaliotis).
git-svn-id: svn://svn.cc65.org/cc65/trunk@4530 b7a2c559-68d2-44c3-8de9-860c34a00d81
