Re: Aw: Re: [stella] Reflex: Source of PAIN!

Subject: Re: Aw: Re: [stella] Reflex: Source of PAIN!
From: "B. Watson" <atari@xxxxxxxxxxxxxx>
Date: Mon, 5 Apr 2004 18:12:51 -0400 (EDT)

On Mon, 5 Apr 2004 KirkIsrael@xxxxxxxxxxxxx wrote:

> Making things slightly worse, I applied that to the definitions of constants,
> so the start of JoustPong has lots of stuff like

The only danger there would be if your `mental model' were screwed up
in such a way that you thought you wouldn't need to use a # when you
referenced the label, because it already has a # when it's defined...



 lda #SOMETHING ; correctly generates immediate mode (bytes a9 45)
 lda SOMETHING  ; generates ZP mode (bytes a5 45)

...if the beginning programmer is used to e.g. macro expansion in the C
preprocessor, he might expect `lda SOMETHING' to expand to `lda #69'.
You and I know it won't... but the C programmer expects to do stuff like:

#define SOMETHING = "#69"

printf("Something is %s", SOMETHING); /* prints: Something is #69 */

Still, he'd just chalk it up to `newbie error' and move on with his

Really there are 2 schools of thought here clashing: one is the `do what I
mean' school (like perl's design, liberal in what it accepts), and the other
is the `don't make any assumptions' or maybe the `bondage and
discipline' school of thought (like Java and C use).

I generally think of assembly language as being the latter... assemblers
tend to be unforgiving, so I expect them to always make you say exactly
what you mean. But what I expect isn't necessarily what you expect, and
neither behavior is `wrong'.

> I guess the ambiguity I was talking about would come from the case
> where someone did something like
>    .byte SomeMemoryLocationLabel
> hoping that it would be filled in with...with...well, frankly I
> don't know what someone would've been hoping to get with that,

Well, hopefully they wanted the value of SomeMemoryLocationLabel (aka
the address SomeMemoryLocationLabel) in their code, because that's
what they'll get... as long as SomeMemoryLocationLabel is located in
zero page.  Otherwise they *should* get an assembly error (trying to
use .byte with an agrument that won't fit into a byte), but what they
actually will get in that case will be just the low byte of the value
of SomeMemoryLocationLabel (just now tested it).... which is a separate,
unrelated bug (or feature?) in DASM.

But this looks `wrong' to me, even though it isn't:

some_table .byte 1, 2, 3, 4
some_table_addr .word #some_table ; normally I'd write `.word some_table'

> since it's "obviously" an "assembly time" kind of thing, which
> is why I'd like DASM to continue not to worry about it.

Well, DASM's been around for what, 15 years now, so I wouldn't seriously
suggest changing it anyway... I'll keep on thinking the extra # characters
are wrong, and you keep thinking they're right, and DASM will keep
working for both of us :)

erk. Sorry about all that ranting, I had 15 minutes to kill (getting off
work now!)

Archives (includes files) at
Unsub & more at

Current Thread