In my OS/architecture class we used a textbook whose author had piled on so much macro assembling on top of SPARC asm (macros all in m4, naturally) that he in effect was writing the book using a personal high-level language constructed out of gobs of m4. Like the bizarro-world version of personalized language construction in Lisp-land...

Was this book (the first review complains about the same thing): http://www.amazon.com/gp/product/0130255963/ref=as_li_ss_tl?...

I used this book for OS/architecture class as well.

I think the use of m4 needlessly complicated the material.

This. Microsoft MASM is the canonical example of one.

Born in 1981, still being updated today:

http://en.wikipedia.org/wiki/Microsoft_Macro_Assembler

Indeed, I pretty much learned programming on the C64 using Turbo Assembler which had macro functionality.

I learned assembly on the Atari 8-bit (like the C64 and AII, all of which used a variant of the Motorola 6502) which had an assembler named MAC/65. MAC, of course, was short for macro. This was in the early 80's also. Good times.

http://en.wikipedia.org/wiki/MAC/65

AFAIK the Turbo Assembler was producing x86 bytecode, how would that work?

You must be confusing Turbo Assembler on the Commodore 64 with something else, the C64 used an 8-bit cpu called 6510

> x86 bytecode

What?!

I guess he's talking about Borland's Turbo Assembler that was coming with Turbo Pascal: http://en.wikipedia.org/wiki/Turbo_Assembler

My remark was because the OP used bytecode to describe assembly opcodes.

The usage is nonstandard, but it provides an interesting perspective. What if he was planning to run the X86 code on a virtual CPU, is his usage then correct? Does the nature of compiled code change if it is executing on a "real" machine instead of a virtual one?

I would say yes, given that some bytecode instruction sets make a CISC processor look like a RISC one.

Try the 60's.

Also CISC instruction sets (VAX, 68k) were already pretty high-level.