Yes, that was precisely my point, and thank you for stating it more clearly and concisely than I did.  The VAX MACRO compiler takes in VAX assembly source code, not binary VAX instructions.

The discrete transistor -> integrated circuit transition (2nd generation-> 3rd generation) eventually resulted in enough of a speedup that microcode implementations of instruction sets such as System/360 offered acceptable performance at a low manufacturing cost.  IIRC System/360 models 75 and up were done completely in hardware--no microcode.  S/360 models 67 and down were microcoded.  The lowest end S/360, the model 25, was actually a 16-bit machine.   All the S/360s from the 65 and down had microcoded emulators for 2nd generation IBM architectures such as the 1400.  The emulators usually ran faster than the real hardware.

The emulators were there to accommodate data centers that had lost their source code for mission critical applications.  There was also translation software available that would translate 2nd generation machine code into COBOL.  I remember their ads appearing weekly in ComputerWorld.  It showed a data center manager smacking his forehead.  The headline of the ad read, "1400 emulation?  In your 19xx budget?"  I never had personal experience with the translator, but I'm told that the resulting COBOL was hard to maintain.

Another example of using instruction set emulation was the IBM 5100 Portable Computer.  Released in 1975, this was a desktop-sized machine with an attached keyboard and small CRT screen.  One interacted with it in either APL or BASIC, the language selectable by a toggle switch.  64K of memory was available to the user.  Internally the machine had a CPU codenamed Palm that was used in many of IBM's peripheral controllers.  The hardware had two 64K banks of ROM and one 64K bank of RAM.  One of the ROM banks held the BASIC interpreter and the other bank the APL interpreter.  The front panel toggle switch selected which ROM bank was in use.

The BASIC interpreter was implemented in native Palm code.  But the APL interpreter was APL\360, in S/360 machine code.  There was a S/360 instruction set emulator written in Palm code that interpreted the APL\360 interpreter.  This sort of situation delivers horrible performance.

During grad school I interned for a few years at IBM's Cambridge Scientific Center (CSC) in Cambridge, MA, the birthplace of CP-67, the virtual machine software system, and CMS (Cambridge Monitor System), an interactive OS that ran in CP-67 virtual machines.  The CSC folks got hold of a 5100 and were fascinated in its S/360 instruction set emulation facility.  The first versions of CMS ran in less than 64K on a S/360 model 40.  CSC had a project to take modern CMS, put it on a bit of a diet, and then run it on the 5100, thus creating an interactive, desktop S/370.  Project programming was done on a large S/370 mainframe.  The problem was getting the code onto the 5100.  They eventually wrote an OS/VS link editor in APL that ran on the 5100 and linked OS/VS object files into executable images stored on the 5100's floppy disk.  They wrote a APL shared variable module called delta-S360 that caused the Palm processor's S/360 emulator to stop emulating the APL interpreter and instead emulate instructions loaded into an APL variable passed as a parameter to delta-S360.

The APL link editor ran as slow as death.  It processed one object file card image every 10 seconds or so and took hours to link a program.  I was given the task of writing an OS/360 link editor that could run standalone on the 5100's S/360 emulator.  It was invoked from the APL interpreter by a delta-S360 call.  With the APL interpreter out of the picture, my link editor ran the floppy disk as fast as it could go and reduced link time from hours to minutes.

Knuth was right about multiple levels of emulation/interpretaton.

-Paul W.