>Now to actually absorb them, given that if I were to read your >comments literally, I'd assume that the intermediate code would be >machine independent.
not if you're reading my comments literally. i'd already observed that "they contain target-dependent code but not precise machine instructions", before saying "only the loader knows or needs to know the bit patterns and peculiar properties of the actual machine". given that it's target-dependent it certainly isn't machine independent. it's target-dependent because register allocation has been done with regard to the target register set, and because the compiler has generated code that refers to instructions (including virtual instructions) available on that target (eg, AMULHW or AMULHWCC on the powerpc, but not on the x86). the set of instructions used by the compiler for a given target is represented by a set of enumeration values in 5.out.h, q.out.h, etc. the compiler and assembler cannot use anything outside that set. the instructions are represented in the .[8kvq5...] files by those enumeration values; that includes virtual instructions and pseudo-ops such as ANAME, ASIGNAME, ATEXT, and AGLOBL. the enum values are written as one or two-byte value, followed by operand descriptors. the operands to instructions resemble those on the target, so that they can use double-indexing if the machine supports that, or shift/rotate (cf. ARM). they are virtual to the extent that some irregularities of the actual processor are glossed over, and also because external references are by name, not by address. the representation is therefore an abstraction of the real machine, but it isn't machine independent. different machines have different types and numbers of operands, and different representations in detail for them. libmach has modules 5obj.c kobj.c etc. that interpret the formats for the benefit of nm and ar amongst others.
