From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-01-20 16:19:26
Hi!
> I encountered a problem: VICE (Version 1.2) under Win32 complains
> about an unexpected token at the end of each line of the token file.
> It's CR/LF sequency which VICE does not like, since VICE always uses
> Unix style line terminator (LF); so, currently, the label file is not
> usable at all unless the file can be converted to unix style (which I
> did for testing purposes with the help of Linux, and it worked well).
I would say that this is a VICE problem, not a ld65 one. The label file
and all other macro like files in VICE *are* text files, so VICE should
treat them as such and expect the correct line termination for the
operating system it runs on. If VICE expects a simple LF, it is not
possible to generate a macro or label file using a text editor under
Windows, something that would be useful.
The VICE people may of course have a different view of the problem:-) I
will send them a mail, they are usually very responsive.
> Is there an option I did not find or is it even planned to generate
> further debugging information, i.e., a mapping of code lines to
> memory addresses, so that there would be the option of doing something
> like a source level debugging? (Yes, I know, VICE lacks the functio-
> nality 'til now, but I want to know of cc65 itself does something like
> this)?
Here is what I have currently in mind (this does mean that I have put some
thoughts into it - it does not mean that the features will be in one of
the next versions):
* I will add a type for the generated symbols. This will allow a
debugger to distinguish between memory labels, zero page locations and
other constants. Currently all debug symbols are equal, and VICE uses
the first symbol it finds to display memory reference - this often
wrong.
* Symbols will have an associated range, that says for which code
addresses the symbol is valid. Currently local symbols are placed in
the global address space and are visible from eyerywhere. This leads
to a symbol table pollution.
Both things are possible with the current compiler, but they are not
supported by VICE. So, to make them usable, I will have to propose an
extension to the VICE monitor.
* Write a debugger that resides on the PC, has knowledge about all
debugging information and connects to the real machine via a serial
link using a small cc65 module that has to be linked to the
application.
This would mean that it is possible to develop the debugger
independent of VICE, and that it is possible to support all platforms,
not only the platforms that are emulated by VICE (the Plus/4 comes to
mind, since it already has a 6551 UART).
If have put some work into serial support lately to lay the ground for
such a debugger, but it is a lot of work, so don't expect this to come
soon. Currently it's just an idea.
A source level debugger (as suggested by you) will not be possible with
the current compiler, since the RD parser does not generate an abstract
intermediate code. This means there is no chance to keep the debug/line
information intact while the optimizer works on the generated assembler
code.
> I hope I will enjoy cc65.
I hope that, too:-)
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET