BitWise wrote:
I've seen *, $, ., and @ used in various 6502 assemblers over the years to represent the origin.
Thanks for bringing the .DBYTE directive to my attention. I'll add it to my implementation.
If BigDumbDinosaur is actually using the operating system his signature suggests he does then he has a complete arsenal of text processing tools at finger tips that can rearrange his code. 'sed' would make light work of replacing most of them.
As would awk and a few others. I do all my development on Linux (a dual Opteron box, no less). However, the idea is to not have to make wholesale source code edits to conform to non-standard assembler syntax.
BTW, the use of * to reference the program counter has existed since before the invention of the microprocessor. I recall seeing it in IBM 7094 assembly language programs in the 1960s (despite the availability of several high level language compilers, a surprising amount of assembly language was written for that machine).
The *=*+n idiom I can recall from the earliest 6502 assemblers. In fact, in Lance Leventhal's first edition of 6502 Assembly Language Programming, that device is illustrated. Commodore's MADS, which was a C64 implementation of the MOS Technology reference assembler from the late 1970s, used * to reference the program counter and *=*+n to advance it (*=*-n would cause an error, IICR). DevPak for the C-128 did likewise. WDC, whose founder was one of the architects of the original 6502 and one of the two authors of the assembly language syntax and mnemonics, also uses * as the program counter definition in their recommended assembler syntax and in their ProSDK.
Use of $ or @ to refer to the program counter gives rise to a potential ambiguity. In a standardized 6502 development environment, those symbols are used to represent base-16 and base-8 radices, respectively. * has no such meaning and thus can't be misunderstood as a radix. Why create an inherent interpretation conflict by deviating from an accepted standard?
My point to this diatribe is there is a long history behind the syntax found in compliant 65xx assemblers. As soon as one decides to deviate from the accepted standards, either because one wishes to be different, or because one isn't fully conversant with them, one succeeds in writing something that people like me who have been in this literally for decades aren't interested in using.