Re: [REPOST][PATCH v4] H8/300: sim: Fix simulator hang caused by qsort on Windows/MinGW

[Jan Dubiec <jdx@o2.pl>]

On 8.10.2026 04:04, Jeff Law wrote:
[...]

> This seems generally sensible to me.  I'd probably kill that ldm/stm 
> special case, particularly if the new comparator avoids the problem.

I'm not sure what you mean by "new". That said, using a stable sorting 
algorithm avoids the problem, but only incidentally.

The root of the problem is that the third nibble of the LDM/STM opcode 
is marked as DATA in h8_opcodes[]. As a result, if h8_opcodes[] is 
sorted in the "wrong" order, decode() may decode MOV.L @ERs+, ERd as 
LDM/STM. The first three bytes of the MOV.L instruction are 01 00 6D, 
whereas those of LDM/STM are 01 X0 6D, where X is 1, 2, or 3. That's why 
I added the special case.

IMO, the LDM/STM definition should be split into three separate 
instructions, as specified in the "H8S/2600 Series, H8S/2000 Series 
Software Manual". However, I didn't want to modify h8_opcodes[] because 
it is also used by other tools.

Also, the simulator is slightly slower when using a stable sorting 
algorithm.

> I'd instead be more interested in tripping an assert if we ever have two 
> things compare equal
An assert doesn't make sense here because equal comparisons occur "all 
the time". For H8/300H, the comparator is called 80919 times and returns 
zero 22434 times. For H8S, the corresponding numbers are 94315/26963, 
and for H8SX, 79552/23240. The h8_opcodes[] array contains 8484 elements.

/J.D.