Re[2]: [cc65] quickly getting the adress from somewhere in the code

From: Mats Andrén <matan3251student.liu.se>
Date: 2004-09-27 16:54:07
Monday, September 27, 2004, 11:32:07 AM, you wrote:
>>>>>> "UvB" == Ullrich von Bassewitz <uz@musoftware.de> writes:

UvB>> I cannot imagine a situation where this would be more useful than
UvB>> using any of the other information sources given by the linker
UvB>> (for example the debug info file). Can you give an example for a
UvB>> common situation where this command could be helpful, that cannot
UvB>> be handled by other means?

> FWIW I've missed this too. I use it like Mats, to get addresses
> printed out during assembly that I can check in the monitor when the
> program is running - without having to export a variable and find it
> via the map/lab file. Or to print out how many bytes are free in a
> chunk of code or a table. It's just a convenience features though

Exactly. It is "just" (!) for convenience as a general quick and easy
way to get in touch with properties of the generated binary or
contents in c64 memory when working with a cartridge with a monitor.
Letting you know what expressions evaluate to and so on. Even though I
understand that it is possible to get most kinds of information out of
ld65 somehow I think it's obvious what's most usable:

 - Seeing an address:
   .ldprint *
   .ldprint somelabel

 - Seeing what an expression evaluates to:
   .ldprint (table1end-table1start)*NUMBEROFTABLES

 - Seeing what an expression evaluates to, with an additional string
   description:
   .ldprint "generated data size: ",(table1end-table1start)*NUMBEROFTABLES

..and then just read what it says on the screen when
assembling/linking (and just waiting for the binary to transfer to the
c64 anyway, in my specific case), compared to:

 - Seeing an address:
   flepp: .export flepp
   ...and then turning on "-vm" in the linker and loading and browsing
   the mapfile (which is then also filled with lots of other
   information that is not straight to the current point) or checking
   the labelfile by reloading that file into the texteditor or by using
   an additional grep command on the labelfile or something.

 - Seeing what an expression evaluates to:
   ...is this even possible now? As far as I understand, you can only
   check weather an expressíon evaluates to something specific or not
   with the ".assert" command? Not what it evaluates to.

In fact, I didn't even understand how to easily check what constants
evaluate to, even though they are determined already in the assembler
phase? I may have missed that part though. As far as I could see you
can only output the name of a constant (with ".out .string(CONSTANT)"
which is quite pointless for the purposes I describe here and
obviously not what these commands are meant for) and not the value
associated with it. Can be useful when a constant is calculated from a
complicated formula depending on lots of stuff.

Even though it is "just for convenience", it's a feature that I use
again and again while coding, and having to do it in unnesescarily
complicated ways just makes me a bit irritated. I see this as a more
basic feature than most of the other commands in ca65 since it has do
with ease of interaction during the daily coding process, where "trial
and error" makes you want to know "what really happened" in many
different ways depending on what kind of project you're working on.
It could be used to a lot more than just checking where a label ends
up. Even though I'm happy that a linker takes care of stuff for me,
I'm unhappy when it's not really easy to find out _what_ it does for
me.

Still, I may have missed something, since I'm quite new to the whole
package and not fully aware of the workings of all available commands
and so on. Except for this specific aspect, I find ca65+ld65 to be
really great.

Have a nice day!

/Mats

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Mon Sep 27 16:52:48 2004

This archive was generated by hypermail 2.1.8 : 2004-09-27 16:52:57 CEST