Ah yes, I had forgotten that. The first time I wrote an assembler was to learn Forth on the HP-71 20 years ago. I did the same thing just to make it easier (or so I thought at the time).


Ok, maybe I should have said "normally," or "in most cases." After I wrote the above I did think of times you might use a less-than-perfect macro just because you already have it and didn't want to write another. (I'm not 100% innocent myself.)

It's also always possible for certain conditions to escape the programmer's attention, for example that

Code:

      IF_<condition>
         actions1
      ELSE
         actions2
      END_IF
      RTS

is not as efficient as

Code:

      IF_<condition>
         actions1
         RTS
      END_IF
      actions2    ; (the "else" code)
      RTS

because the branch put in by ELSE takes more time and memory than the extra RTS; or that a big CASE structure might not be nearly as efficient as a look-up table of execute addresses. The examples I gave were mostly just to get rid of gobs of labels and hide the jumps though, arriving at the very same output but from a more-readable source code. Obviously you need to know what's in your macros.

Works fine for me.

http://www.obelisk.demon.co.uk/6502/6502.zip

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Oh...I went to your site (www.obelisk.demon.co.uk), followed the links and that was where things broke. That is a different link.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The development version of the assembler I play with as a hobby doesn't have this specific ability, but it's possible to implement something like it by splicing and dicing strings. For the 6502 an IF..ENDIF might look like this:



The first macro creates, saves and uses a target label. The second retrieves, uses and discards that same label.

"putbacks" is a pseudo op that evaluates its argument as a string expression and then pushes the result back onto the input stream, so it becomes the next line the assembler sees. I implemented it specifically for the purpose of creating macros like these.

Because arbitrary string expressions are allowed it's possible to do this:



but that loops only so many times before the assembler says "enough!"

I've created demo nesting IF..ELSE..ENDIF and WHILE..ENDWHILE "high-level structures" using macros like these. They can be pushed farther, though I'm not sure exactly how far.

I took a look but didn't see everything I wanted. There's no obvious way to assemble tables that will work with "push/push/rts" program routing, reference the program counter or advance the program counter without generating code. Also, I may have missed it as I read the documentation, but I don't see an obvious way to have the assembler directly output to a Motorola S-record. Having to use a linker just to produce a simple program seems like an unnecessary extra step.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The assembler has .WORD and .BYTE directives to create data tables. Which you use depends on whether you want the address high and low bytes together or in separate tables.


The program counter is referenced by a $ in an expression.


The directive .SPACE increase the program counter. Change the origin will work in absolute mode - will have to check relative mode.


You have to link to generate S19 but it only takes a split second and you can always create a make file for your project to automatically link after assembling.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

The directive that is missing is .DBYTE <address>, which assembles <address> in big-endian order, producing a look-up table suitable for "push/push/rts" coding. .WORD assembles <address> in little-endian order.



Completely non-standard. Using your assembler would mean editing many source files in which the directive *=*+n is used. Why deviate from the MOS Technology (and WDC) standards that were published years ago and used in all commercially developed assemblers? I don't mean to be critical, but the above are why I decided to create my own assembler, one that would be 100 percent MOS syntax compatible.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The $ is the only one I've ever heard of for this; so whether it's original or not, it seems standard to me. Is there an advantage to "*=*" other than that someone used it long ago? A text editor's search-and-replace feature would make very quick work of changing the source code over.

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.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

teamtempest, you got me excited for a minute, but I re-read my assembler's manual again (which I haven't looked at in a long time) and it just doesn't give any way to do that. I might still try to do the structure macros with variables (instead of a stack), although it won't be as neat, requiring a macro parameter, as well as care to avoid using the same variables for two or more nested structures.


and BitWise:
Ah yes, I forgot about the * .

Looking through the 6502 gcc posted on the other thread, I notice an interesting assembler feature mentioned:

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

A couple of small tweaks and ...

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I have to concur with BDD here; I've only seen $ used once, and this was for a Commodore 128 assembler which included support for the Z-80. Note that $ is used as the current location pseudovariable on all 8080, Z-80, and 8085 assemblers. (It's not used much, if at all, on 8086 and later assemblers, due to the inherent relocatability of segments.) They chose $ over * to allow the use of the current location to be used in expressions containing multiplication. Intel hex notation (e.g., 0DEADBEEFH versus $DEADBEEF) was born of necessity here.

Note that using $ for the current location pseudovariable effectively precludes its use from identifying hexadecimal constants. While a sufficiently complicated parser can be made to detect isolated $ characters from prefix $ operators (absolutely requiring at least an LL-parser to do this), it opens up such errors as $1 being syntactically valid when you meant to type $+1. This is an amazingly common error to make on keyboards scanned at 60Hz (e.g., the C64's keyboard) if you're a fast typer like I am.

BDD, you're right that *=*-N was an error, primarily because MADS processed source listings sequentially, and wrote out blocks of code using sequential or PRG files (I forgot if it supported tape output, not ever having used a datasette with my C64). These files lacked random-access seek capability, so going backwards in the binary image was effectively forbidden by the DOS. The assembler design reflects this.

I think this:



will only work for in-memory assemblers, as you jump backward in address space. Or what is the semantics when you write out the assembled result into a file?

André