On Saturday, October 21, 2023 at 8:23:36 AM UTC-5, retrogear wrote:

This may have been documented before but with assembling MOV M,M with assemblers ASM or MAC, debuggers DDT or SID produces the 76h HLT opcode with no error reported. I just discovered this today for myself. Has anyone else heard of this ? Apparently

MOV M,M is not valid even though moving other registers upon themselves is valid ?

Larry G

This is not surprising, it is just something everyone knew back then (that HLT was the same as the MOV M,M instruction).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

However, the TDL assembler flags it.

TDL Z80 CP/M DISK ASSEMBLER VERSION 2.21 PAGE 1 MOVM -



0100 .LOC 0100H
.IDENT MOVM

; there is no MOV M,M
; register R evaluates as follows:
; B=0 C=1 D=2 E=3 H=4 L=5 M=6 A=7

0100 77 MOV M,A
0101 70 MOV M,B
0102 71 MOV M,C
0103 72 MOV M,D
0104 73 MOV M,E
0105 74 MOV M,H
0106 75 MOV M,L
A 0107 76 MOV M,M?

.END

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, October 21, 2023 at 10:38:40 AM UTC-5, retrogear wrote:

However, the TDL assembler flags it.

TDL Z80 CP/M DISK ASSEMBLER VERSION 2.21 PAGE 1
MOVM -

0100 .LOC 0100H
.IDENT MOVM

; there is no MOV M,M
; register R evaluates as follows:
; B=0 C=1 D=2 E=3 H=4 L=5 M=6 A=7

0100 77 MOV M,A
0101 70 MOV M,B
0102 71 MOV M,C
0103 72 MOV M,D
0104 73 MOV M,E
0105 74 MOV M,H
0106 75 MOV M,L
A 0107 76 MOV M,M?

.END

M80 also complains about MOV M,M, but produces valid output files anyway.

DRI tools do less checking. But both (M80 and DRI tools) have some much more egregious lapses, such as turning "MVI A,B" into "MVI A,0" and "MOV A,0" into "MOV A,B". Those occur without any messages at all.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

retrogear schrieb am Samstag, 21. Oktober 2023 um 15:23:36 UTC+2:

Apparently MOV M,M is not valid even though moving other registers upon themselves is valid ?

This would need a 2 address machine, which it isn't.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/10/2023 1:05 am, Douglas Miller wrote:

On Saturday, October 21, 2023 at 8:23:36 AM UTC-5, retrogear wrote:

This may have been documented before but with assembling MOV M,M with assemblers ASM or MAC, debuggers DDT or SID produces the 76h HLT opcode with no error reported. I just discovered this today for myself. Has anyone else heard of this ? Apparently

MOV M,M is not valid even though moving other registers upon themselves is valid ?

Larry G

This is not surprising, it is just something everyone knew back then (that HLT was the same as the MOV M,M instruction).

Only to those who tried it. That MOV M,M results in HLT is either very significant
- or about as meaningful as an image seen in a toasted cheese sandwich.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, October 21, 2023 at 8:16:50 PM UTC-5, dxf wrote:

On 22/10/2023 1:05 am, Douglas Miller wrote:

...

This is not surprising, it is just something everyone knew back then (that HLT was the same as the MOV M,M instruction).

Only to those who tried it. That MOV M,M results in HLT is either very significant
- or about as meaningful as an image seen in a toasted cheese sandwich.

It was quite obvious to those that studied the instruction set, which most people had to do in order to program effectively in assembly. A quick look at the instruction table shows HLT in the position where MOV M,M would be. Just looking at the binary
instruction coding made it clear. Intel simply used MOV M,M to mean HLT since it was a useless instruction otherwise. It may have even had some undesirable side-effects if left to the logic to actually try and do a MOV M,M, thereby protecting the CPU
from lockup or some other problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/10/2023 1:35 pm, Douglas Miller wrote:

On Saturday, October 21, 2023 at 8:16:50 PM UTC-5, dxf wrote:

On 22/10/2023 1:05 am, Douglas Miller wrote:

...

This is not surprising, it is just something everyone knew back then (that HLT was the same as the MOV M,M instruction).

Only to those who tried it. That MOV M,M results in HLT is either very significant
- or about as meaningful as an image seen in a toasted cheese sandwich.

It was quite obvious to those that studied the instruction set, which most people had to do in order to program effectively in assembly. A quick look at the instruction table shows HLT in the position where MOV M,M would be. Just looking at the binary

instruction coding made it clear. Intel simply used MOV M,M to mean HLT since it was a useless instruction otherwise. It may have even had some undesirable side-effects if left to the logic to actually try and do a MOV M,M, thereby protecting the CPU
from lockup or some other problem.

HLT needed to be assigned an opcode and 76h was available. The encoding for M is 6
- as is PSW or SP. None of these are regular registers. There's no reason to expect
MOV M,M to work any better than MOV M,PSW or MOV M,SP.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, October 21, 2023 at 11:04:59 PM UTC-5, dxf wrote:
...

HLT needed to be assigned an opcode and 76h was available. The encoding for M is 6
- as is PSW or SP. None of these are regular registers. There's no reason to expect
MOV M,M to work any better than MOV M,PSW or MOV M,SP.

There were other opcodes available on the 8080. The reason MOV M,M was chosen likely had to do with minimizing the total amount of logic needed to prevent MOV M,M from being executed and still implement HLT somewhere else. If MOV M,M was allowed to "fall
through" the normal MOV instruction logic, it would (best case) have resulted in a 9 T-state instruction that served no purpose - if it would have worked at all. Depending on the internal logic of the CPU, it might have also been problematic to
implement. So it seems logical that they would override only one instruction (MOV M,M) and implement HLT, rather than make MOV M,M work (cause no harm) and still implement HLT by overriding some other opcode. Keep in mind that the unused opcodes still
activate internal logic, but it would be desirable for them to be as benign as possible. Of course, this is just a theory of their motivations. If one wanted to study the internal logic diagrams of the CPU, it would probably be clearer why MOV M,M was
chosen for HLT. Also keep in mind that there was not an excessive amount of free space on the 8080 - they already had to offload much to the other two chips of the set.

Also consider that the instruction decode logic was (had to be) simple. if the high two bits of the instruction are "01", then the MOV logic is activated. The rest would be just mechanical interpretation of the source and destination operands as B,C,D,E,
H,L,M, or A. So, opcode 76H (octal 166) could not have meant anything other than MOV M,M (unless the decoding was overridden to implement something else entirely, such as was done for HLT).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 22 October 2023 at 12:25:08 UTC+1, Mark Ogden wrote:

On Saturday, 21 October 2023 at 20:33:56 UTC+1, Douglas Miller wrote:

On Saturday, October 21, 2023 at 10:38:40 AM UTC-5, retrogear wrote:

However, the TDL assembler flags it.

TDL Z80 CP/M DISK ASSEMBLER VERSION 2.21 PAGE 1
MOVM -

0100 .LOC 0100H
.IDENT MOVM

; there is no MOV M,M
; register R evaluates as follows:
; B=0 C=1 D=2 E=3 H=4 L=5 M=6 A=7

0100 77 MOV M,A
0101 70 MOV M,B
0102 71 MOV M,C
0103 72 MOV M,D
0104 73 MOV M,E
0105 74 MOV M,H
0106 75 MOV M,L
A 0107 76 MOV M,M?

.END

M80 also complains about MOV M,M, but produces valid output files anyway.

DRI tools do less checking. But both (M80 and DRI tools) have some much more egregious lapses, such as turning "MVI A,B" into "MVI A,0" and "MOV A,0" into "MOV A,B". Those occur without any messages at all.

It was not uncommon for assemblers of the period to treat registers as numbers, with B = 0. This would explain why the instructions you noted do not issue a warning. Although I haven't checked, I would
not be surprised if MOV 7,0 was also treated as MOV A,B.

I have now confirmed MOV 7,0 works with M80 as I suspected and also note that M80 also supported opcodes as operands, so MVI A,CMA is equivalent to MVI A,2FH.
Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Apparently MOV M,M is not valid even though moving other registers upon themselves is valid ?

This would need a 2 address machine, which it isn't.

Interesting, so a good place to halt rather than try something impossible.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 22, 2023 at 6:25:08 AM UTC-5, Mark Ogden wrote:

It was not uncommon for assemblers of the period to treat registers as numbers, with B = 0. This would explain why the instructions you noted do not issue a warning. Although I haven't checked, I would
not be surprised if MOV 7,0 was also treated as MOV A,B.

DRI documentation actually states this. You also see in DRI source code that they rename registers in certain places, doing something like:

FOO EQU B
...
MVI FOO,123
...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 21 October 2023 at 20:33:56 UTC+1, Douglas Miller wrote:

On Saturday, October 21, 2023 at 10:38:40 AM UTC-5, retrogear wrote:

However, the TDL assembler flags it.

TDL Z80 CP/M DISK ASSEMBLER VERSION 2.21 PAGE 1
MOVM -

0100 .LOC 0100H
.IDENT MOVM

; there is no MOV M,M
; register R evaluates as follows:
; B=0 C=1 D=2 E=3 H=4 L=5 M=6 A=7

0100 77 MOV M,A
0101 70 MOV M,B
0102 71 MOV M,C
0103 72 MOV M,D
0104 73 MOV M,E
0105 74 MOV M,H
0106 75 MOV M,L
A 0107 76 MOV M,M?

.END

M80 also complains about MOV M,M, but produces valid output files anyway.

DRI tools do less checking. But both (M80 and DRI tools) have some much more egregious lapses, such as turning "MVI A,B" into "MVI A,0" and "MOV A,0" into "MOV A,B". Those occur without any messages at all.

It was not uncommon for assemblers of the period to treat registers as numbers, with B = 0. This would explain why the instructions you noted do not issue a warning. Although I haven't checked, I would
not be surprised if MOV 7,0 was also treated as MOV A,B.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 22, 2023 at 7:10:00 AM UTC-5, retrogear wrote:

Apparently MOV M,M is not valid even though moving other registers upon themselves is valid ?

This would need a 2 address machine, which it isn't.

Interesting, so a good place to halt rather than try something impossible.

Actually, it's not impossible but just effectively a NOP, the same way MOV B,B etc are. What's impossible is to have MOV M,M move data from one location to another. Since "M" is defined as the memory location pointed to by HL, MOV M,M is the same type of
instruction as MOV B,B (just taking more cycles). As I was hypothesizing, it may have been the case that Intel wanted to remove MOV M,M because of problems on the chip, or even just general dislike of such an expensive NOP, and since they had to override
some opcode to get HLT anyway they might as well override MOV M,M and accomplish both goals.

Most of the 8080 instructions fall into opcode patterns which would translate into relatively simple decoding logic on the chip. But some instructions, such as HLT, that have no such pattern would require "more expensive" decoding logic. So if they had
to add this logic for HLT, but also had reason to do something similar to protect programmers from MOV M,M, they may have opted to combine the two and save on decoding logic.

I worked for a company that was one of the first to use the 6800 CPUs, and the owner told of the early batches of (very expensive) 6800 CPUs that had a "hardware bug" where if you executed one of the undocumented opcodes it caused conflicting logic to be
enabled which latched up the chip and resulted in thermal runaway and (literally) melted the chip. It was a pretty high price to pay for making a software error, and of course Motorola fixed it ASAP. But, the point being, these early CPUs were vulnerable
to logic problems when "undocumented" opcodes were executed. Who can say whether a similar situation existed for the MOV M,M instruction, which could explain why it was overridden to implement HLT. Even if there was only uncertainty, it could have
influenced the choice.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/10/2023 11:52 pm, Douglas Miller wrote:

...
Most of the 8080 instructions fall into opcode patterns which would translate into relatively simple decoding logic on the chip. But some instructions, such as HLT, that have no such pattern would require "more expensive" decoding logic. So if they had

to add this logic for HLT, but also had reason to do something similar to protect programmers from MOV M,M, they may have opted to combine the two and save on decoding logic.

Given Intel mnemonics were about making assemblers easy to write, protecting capable users from a single illegal instruction seems unlikely. For a user familiar with the instruction set MOV M,M would automatically raise a red flag as something never seen before. Fans of Z80 mnemonics might expect
their assembler to give warning, but that's a different issue.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, 25 October 2023 at 04:29:33 UTC+1, fridtjof.ma...@gmail.com wrote:

Intel assembler (Intel ISIS or Microsoft M80.COM in 8080 mode, but NOT ASM.COM) had one more
"trick up the sleeve":
Single byte operations can be immediate arguments. This even highlights an error in M80.COM:

0000' CSEG
.8080
O 0000' 06 78 MVI B,(MOV A,B)
0002' 78 MOV A,B
0003' 06 21 MVI B,(LXI H)
0005' 3E 00 MVI A,0
A 0007' 76 MOV M,M
END

Note the O error is fatal! But the code is correct. And MOV M,M does produce 76h, which is correct.
Very "code is data". Zilog assembler didn't have this.

Note for M80 the parentheses around the instructions are not needed. The O error is because of the second comma on the line.
instructions without the extra comma e.g. MVI B,MVI A are fine
For ISIS ASM80, the parentheses are needed but the MVI B,(MOV A,B) does not produce an error
The ISIS assembler also rejects MOV M,M and does not allow the numeric register format e.g. MOV A,0 generates an error.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Intel assembler (Intel ISIS or Microsoft M80.COM in 8080 mode, but NOT ASM.COM) had one more
"trick up the sleeve":
Single byte operations can be immediate arguments. This even highlights an error in M80.COM:

0000' CSEG
.8080
O 0000' 06 78 MVI B,(MOV A,B)
0002' 78 MOV A,B
0003' 06 21 MVI B,(LXI H)
0005' 3E 00 MVI A,0
A 0007' 76 MOV M,M
END

Note the O error is fatal! But the code is correct. And MOV M,M does produce 76h, which is correct.
Very "code is data". Zilog assembler didn't have this.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)