Making MAC macros for other processor instruction sets, anyone done this?

[tschak909]

This was a very common thing to do in software shops, but I'm wondering if anyone kept their macros for e.g. 6502 to be used with a macro assembler like DRI MAC?

This is because, I'm putting together production notes for a video showing how cross system development was done professionally.

-Thom

 

[Chuck(G)]

A near-ancient way of developing software for which no real hardware exists.

One of the ways to implement compilers is to design an abstract architecture and instruction set, then generate abstract code for the instructions using the macro capability and test with an interpretive emulator. Finally, change those instructions to direct host machine language.
Did a BASIC compiler that way for 8085, then quickly ported it to 80186. That work was based on a mainframe COBOL dialect translator.

I believe that Ryan-McFarlane started out that way also--offer BASICs (or FORTRANs) for a wide variety of platforms.

Good mental exercise. But I've never done one for 6502.

 

[MrImprovement]

Do you mean something like this? https://homepage.cs.uiowa.edu/~dwjones/cross/

 

[daver2]

We used two ways:

1. A meta assembler (such as cross-16 or cross-32) that supports a whole range of processors with the option of developing new instruction sets for future processors.

2. A macro tool such as STAGE2.

Dave

 

[durgadas311]

If the endianness of the target CPU is different, you've got more trouble making things like MAC work.

 

[daver2]

Yes, cross-nn had facilities for changing the endianess of the code generated.

Dave

 

[Chuck(G)]

What I mentioned was an abstract machine in the true sense. Input was "tokens" (classified by a preprocessor) output was "operations (something akin to P-code). Thus, you'd have a machine instruction like: "IQTT x,y,z "meaning input and query the next token. if it's of type x, call procedure y, and then transfer to label z." Variations of this instruction might be IQTF and IQFT. Things like the input parser and symbol table manager were done in assembly.

Compilation is really nothing more than making a lot of decisions and generating output according to those decisions. Math and bit-twiddling aren't really important. Most things are lexical.

On an 8080-based system, using a macro processor (ASM80's under ISIS wasn't powerful enough) written in PL/M, we put together a fully functional BASIC compiler and run time in 4 months.
Run-time, since this was a multi-user setup, had to be p-code interpreted (relocation issues, otherwise).

 

[Bruce Tomlin]

I've got my own multi-processor assembler, see sig.

Yeah, you can do that with macros, but really it's kind of a pain in the ass to do that way, and the syntax tends to be screwy to fit the macro system. From what I've been able to tell, Microsoft Basic was originally implemented using a PDP-10 assembler with all sorts of macros to support different instruction sets like 8080, 6800, and 6502. Apparently it could even run native on the PDP-10 itself. But this was back when it wasn't easy to have a computer at all, so they "borrowed" time on a university system.