On 26.10.26 16:10, G. Branden Robinson wrote: > At 2026-10-26T13:55:20-0500, G. Branden Robinson wrote: > > Ease of understanding is not particularly correlated with creative > > effort. Assembly language mnemonics are not readily understood by > > most people in the world, but they tend to perform operations so > > simple that they are not copyrightable. If that weren't true, > > microprocessor architects could not clone another manufacturer's CPU. > > <loud buzzer sounds> > > This is of course not true. Microprocessors decode instruction formats, > not assembly language mnemonics.
Having hand encoded microprocessor opcodes in the late 1970s, I see them and their mnemonics as no more disparate than optical isomers, so I fail to see any incoherence in the original wording. Conflation of the two representations of the common semantics shortens the paragraph, sparing the reader, I think. Having written a couple of simple assemblers, one cross, one native, I'd say that the latter, running in ROM, did indirectly allow the microprocessor to execute mnemonics, by it's own actions, even if not intrinsically, or by runtime interpretation. I.e. that was the communication with it. > Microprocessor programmer's manuals invariably (in my experience) list > mnemonics alongside instruction formats. > > Possibly the fact that assembly is useful primarily for human-to-human > communication is why Intel thought they could plant a stake in the > copyrightability of a set of mnemonics. Yes, maintainability improved, but so did productivity, through assembler mediated instruction construction. And via a disassembler, machine to human communication is much improved when poking about the code actually loaded onto a microcontroller. Even when C source is listed, nothing but hex in between would be a nightmare. Add compiler optimisation, and it's even more uphill. > > For a time in the 1970s, Intel Corporation claimed copyright in > > assembly language mnemonics themselves, considered separately from the > > machine language instructions they represented. That's why the Intel > > 8080-compatible Z80 microprocessor by Zilog used different mnemonics, > > such as "LD" and "ST" instead of "MOV". However, Intel proved unable > > to sustain this position.[B] > > I looked into this, and while not dispositive (nor likely the sole > factor), apparently Intel lost a lawsuit against NEC regarding its V20 > (enhanced) clone of the 8086. > > Maybe other folks can throw some light on the issue. My biggest bugbear was when source and destination operand order swapped between chips' assemblers. That caused me more coding errors than new mnemonics, which only took an hour and a coffee or two before starting coding on a new chip with a different instruction set and register complement. Endianness variation can be hidden with an assembler macro or two in most cases. And where I don't like a mnemonic, or need a new one, I add one with a macro. An example of both for an (8-bit) ATmega: ; Data Pointer (or any word value) initialisation of a register pair. ; Usage: ldiw Y,some_data ; ld r16,Y ; OR lpm r16,Y if some_data is in flash. ; WARNING: No skip instruction can bridge this shorthand for two instructions. .macro ldiw reg,addr ldi \reg,lo8(\addr) ldi (\reg + 1),hi8(\addr) .endm (The Y register pair is R28,R29) Again, both productivity and maintainability improve with the abstraction. (So, maybe, it's turtles all the way down.) Cheers, Erik
