- Code specific to Windows was #ifdef'ed with _MSC_VER so it wasn't included with MinGW. So _MSC_VER is replaced with _WIN32.
- MinGW doesn't support _get_pgmptr() so it is necessary to directly call the Win32 function GetModuleFileName(). This implies including windows.h which in turn causes a name clash with the Win32 function SearchPath(). So the cc65 type SearchPath is renamed to SearchPaths.
added a missing addressing mode for jmp/jml : Absolute Indexed Long
that opcode can be written like jmp[$1234] or jml[$1234]
removed Absolute Inderect addressing mode for jml since it's not a long adressing mode
Actually there's no need to fiddle with any automatic temp file name generation as we can just modify the library path name to generate a perfect temporary library path name.
There's no need to intentionally break things for people trying to build cc65 with some obscure compiler. It's enough to make sure that no new warnings sneak into the code base by having Travis CI builds fail.
- tmpfile() tries to create files in the C: root dir on Windows where users usually don't have access.
- tmpnam() uses the curent dir which doesn't seem to be a good idea either.
- tempnam(NULL,NULL) is supposed to be cleverer.
The 'install' target primarily aims to support pacaking tools. Therefore...
- It just presumes a "capable" install program to be present.
- There's intentionally no 'uninstall' target.
Before the fix, that feature couldn't recognize a standard op-code mnemonic, that wasn't replaced by a macro, if it was on a line without a label.
This patch was written by Jeremy Turner.
The code
void foo(void)
{
int i;
long l = 1L * i;
}
triggered an
Internal compiler error:
Code generation messed up: StackPtr is -4, should be -2
Greg King: "We are lucky that the bug is simple -- a missing "else". The result is that the compiler thinks that it does the opposite of what it actually does: It thinks that it pushes the non-constant expression onto the stack. It doesn't; so, cc65's stack pointer is wrong."
Before this fix, BSS-type and ZP-type segments never were counted. Now, they are counted if their memory areas are filled. (It must be done because their places in the output file are filled.)
The fix allows us to build programs for the CBM510 and CBM610 platforms. We won't see an "Internal error" diagnostic message about a bad file-offset.
If the variable 'prefix' is defined then the builtin search paths are set to
$(prefix)/lib/cc65/... allowing to build binaries intended for installation.
Note that the library build still works with these binaries as it generally
overrides the builtin search paths by setting the CC65_HOME env var.
The target 'atarixl' is to be used for Atari XL (and better) machines.
It will disable the OS ROM and enable the Shadow RAM available on
those machine.
Note: This commit is only the inital step towards for this goal that just
replicates the target 'atari' as a starting point!
The targets allow to run cc65 programs in the sim65 exection
einvironment. As there are no "real" i/o facilities there's no
need for header files. Paravirtualized entry points are mapped
to $FFF0 ff. There's a large cc65 progam area from $0200-$FFEF.
The binary format includes a one-byte header indicating the required
execution environment: The value 0 means 6502 and the value 1
means 65C02. The load adress for the binary is fixed to $0200.
Note: Running sim65C02 programs currently doesn't work bcause
sim65 doesn't actually implement 65C02 opcodes.
The sim65 source code has been a construction site for over a decade.
I was looking for a simple cc65 program execution environment for
regression tests. So I decided to re-purpose sim65 for that task by
removing about everything but the 6502 emulation.
There's no memory mapped i/o emulation whatsoever. Rather exit(),
open(), close(), read() and write() calls are supported by mapping
them through a thin paravirtualization layer to the corresponding
host os functions.
Note: The sim65 6502 emulation provides means to switch between
6502 and 65C02 emulation but currently there are no actual 65C02
opcodes implemented.
There are two reasons for removing this dependency:
- If someone does 'make avail' on the top level Makefile he ends up with
binaries but without libraries - not nice. Better do just "nothing" and
have hin understand that he needs to do 'make [all]' on the top level
Makfile first.
- If 'make avail' is done via 'sudo' it isn't desirable to do a large amount
of work as root.
BTW: I wasn't sure if this dependency is a good thing in the first place
but I saw it in many examples ('install' depending on 'all') so I did it too.
The [un]install make goals have a rather fixed meaning for *ix users. The simple
symlinks provided here don't match the expectations users have from [un]install.
Therefore it is appropriate to rename them to "something" not tied to specific
expectations.
