Brad Smith [Tue, 23 May 2017 01:33:02 +0000 (21:33 -0400)]
ca65 documentation of .define macros, making note that parentheses in ca65 macros are problematic especially when thinking of them as "C style", replacing unclear example with an example showing how accidental parentheses can cause a problem.
Oliver Schmidt [Wed, 17 May 2017 18:56:21 +0000 (20:56 +0200)]
Migrate 'encrypted variables' variables to 'repository settings'.
The GitHub token used for GitHub Pages deployment was revoked (see https://blog.travis-ci.com/2017-05-08-security-advisory) so I took the opportunity to make use of the "new" repository settings feature instead of fiddling with variable encryption again.
mc78 [Tue, 16 May 2017 11:13:09 +0000 (13:13 +0200)]
According to recent comments on my recent pull request, -Wc checking for -E flag has been removed again. Intead, -E flag has been added to cl65 without need of -Wc. Two functions have been introduced to disable compile, link or both. These function remove assigment repetions to DoAssemble and DoLink for litte overhead, having the maintainability in mind.
mc78 [Fri, 12 May 2017 10:19:40 +0000 (12:19 +0200)]
added -E switch to cl65 for >>stop after the preprocessing stage<<.
added compilation and assemblation disable after -Wc -E also with -E beeing part of a comma separated list of arguments
Greg King [Tue, 4 Apr 2017 17:23:44 +0000 (13:23 -0400)]
Fixed the simulations of the stack pointer and the "break" and decimal-mode flags.
* The pointer wraps around the stack page.
* The break flag exists on only the stack, and only after an interrupt.
* 65C02 interrupts clear the decimal-mode flag.
Oliver Schmidt [Mon, 3 Apr 2017 21:20:26 +0000 (23:20 +0200)]
So far the built-in inlining of several known standard function was always (!) enabled and the option -Os enabled additional, potentially unsafe inlining of some of those functions.
There were two aspects of this behavior that were considered undesirable:
- Although the safe inlining is in general desirable it should only be enabled if asked for it - like any other optimization.
- The option name -Os implies that it is a safe option, the potentially unsafe inlining should have a more explicit name.
So now:
- The option -Os enables the safe inlining.
- The new option --eagerly-inline-funcs enables the potentially unsafe inlining (including the safe inlining).
Additionally was added:
- The option --inline-stdfuncs that does like -Os enable the safe inlining but doesn't enable optimizations.
- The pragma inline-stdfuncs that works identical to --inline-stdfuncs.
- The pragma allow-eager-inline that enables the potentially unsafe inlining but doesn't include the safe inlining. That means that by itself it only marks code as safe for potentially unsafe inlining but doesn't actually enable any inlining.
Oliver Schmidt [Sun, 19 Mar 2017 19:32:23 +0000 (20:32 +0100)]
Hide stdout of tests returning an exit code.
Now that we doubled our tests by running them for both 6502 and 65C02 Travis CI complains (again) about a too long build output. So let's reduce it by omitting the (useless) stdout of tests.
Oliver Schmidt [Sun, 19 Mar 2017 19:07:19 +0000 (20:07 +0100)]
Run test for the 65C02 code generator / runtime too.
Now that sim65's 65C02 support is actually functional we can run test for the 65C02 support in the compiler and the runtime.
We learn the hard way this is a good idea as there are tests failing when built with optimizations for the 65C02:
- val/compare7
- val/compare8
- val/compare9
- val/compare10
- val/or1
This change includes some cleanups, removal of mainargs.s (game console
programs never have arguments), and a workaround for a problem I'm seeing.
The problem is that sometimes (in fact, more often than not) the clrscr()
call in testcode/lib/joy-test.c writes some garbage chars on the screen (most
often a "P"). Could be my hardware (I haven't seen it on MAME), but to
me the root cause is still unknown.
projects / cc65 / log