Re: [cc65] start adress

Hi!

On Thu, Apr 29, 2004 at 10:05:38AM +0200, carlos wrote:
> as i'm porting some old code, which was written with turbo assembler on the c64, i don't want always to use the linker config file.
> there is the command line option for ld65 -S xxxx, with which you can pass a start adress. it works only with cpu type none, which is correct. if you use ld65 --start-addr xxxx it won't work. if you use cl65 --start-addr it won't be passed to the linker.
> this is ok for now, because you can work around with using seperate calls to ca65 and ld65.

The start address *is* passed to the linker, but only the "none" builtin
config file makes use of it. The start address is inserted into the config
file where the %S key is found. Evaluating %S in other standard configs but
"none" won't work, because the startup code and several pieces of the platform
code depend on a specific memory layout. But you are of course free to change
that for your own purposes: All you have to do is to create a config file that
uses %S in the right places, and you will be able to pass the start address to
the configuration.

> but in ca65, the second version, where there is a space between the macro name and the first bracket will be interpreted like the first one of the #define macros. so the assembler complains about not closed brackets and so on.

The C preprocessor is a very old concept that is unclean and non ortoghonal in
some places. Do you now any other place in a C program where "missing
whitespace" does make a difference? The answer is of course "no". No one would
expect

	while(1) {

to behave differently than

	while (1) {

or

	while( 1 ) {

ca65 doesn't have a real "preprocessor". The .define style macros are
implemented as part of the parser. This means that tokenization adheres to the
same rules as in the remainder of the program. As a consequence, whitespace
between tokens is optional - not in a few places, not in most places, but
everywhere.

> if often use the defines likethis:

.define style macros where never thought for this. They are NOT the same as C
style #define macros and usage of .define style macros is strongly
discouraged. The reason why these macros do exist is NOT to mimic C style
macros. They were added when I got payed by a company to make ca65 a
replacement for a proprietary assembler. Instead of branching ca65, adding the
necessary stuff and then forget this version, I thought of concepts, how to
interact with the low level assembler parts to emulate or mimic features of
other assemblers. One result was the .feature command, another were .define
style macros.

So the first rule for .define style macros is: 

	Don't use them.

And the second rule for .define style macros is: 

	If you do really need to use them, never ever complain if you shoot
	yourself in the foot, because .define style macros are made especially
	for this purpose.

> .define scrw 40
> .define scrn $400
> .define x ??
> .define y ??; any numbers ok
> .define adr y*scrw+x+scrn

This is a typical example for a misuse of these macros. Use

	scrw = 40
	scrn = $400
	xpos = ??
	ypos = ??    	; any numbers ok
	adr  = (ypos * scrw + xpos + scrn)

and all your problems will vanish. In addition, the symbols will adhere
scoping rules. Look at this example:

	.define	xpos	4
	...
	...
	.struct	point
	     	xpos	.word
	     	ypos	.word
	     	color	.byte
	.endstruct

misuse.s(2345): Error: Invalid storage allocator in struct/union

Who would realize what the real reason for the error mesage is, if the two
declarations above are burried in a source file with a few thousand lines of
code?

Regards


	Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.