On further reflection, I am thinking that the upper bound check can be done with an unsigned test.

Concur?

I might be completely wrong, but doesn't PASCAL allow signed indices?

If you're just comparing a 16-bit value to another, you can almost always replace SEC SBC with CMP for the low byte, signed or unsigned.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Yes it does.

Consider this:



There are two ways to compare 16-bit numbers:

and

For the lower bound, we need the difference anyway, so do the subtraction.

For the upper bound, I'll have to analyze the two methods.

Edit: Oh, I see what you are saying. Since the difference is not kept, do a compare of the low bytes instead of a subtraction...

That's what I meant (although in hindsight checking for "<=" or ">" or "=" or "<>" isn't as nice as checking for "<" or ">=" if you use CMP on the low byte, because you might need the low result later).

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I have done some tests for the 6502, Z80, K1801VM1, 8088, and 68000 which have to do the same Mandelbrot calculations. Results are here. It seems that for intensive 16-bit calculations the 6502 shows rather mediocre results. However, getting good optimized code for the Z80 is a very long and expensive process.

_________________
my blog about processors

The linked page says:



I am not familiar with pce-ibmpc. Did you measure the time using a stopwatch or does the emulator report the number of CPU cycles used?

The fastest code in an emulator as measured with a stopwatch is not likely to be the fastest on actual hardware. It is not unlike trying to optimize code for a BASIC compiler as opposed to for one of the many interpreters.

Code optimization on x86 processors is notoriously difficult. If you have ever read The Zen of Assembly Language by Michael Abrash, you will know what I am talking about.

For instance, your code does not make use of the STOSW instruction which is especially advantageous on the 8088/8086 processor but not so much on modern members of the family.

For me, it's a major difficulty with any kind of comparison using hand-coded assembly - you need to be able to marshal the same level of expertise with each micro. Not insurmountable, but otherwise you may leave unrealised improvements for some which distort the rankings.

Let me show you the original PDP-11 assembly for the main loop.

It is just a straightforward implementation of the Mandelbrot fractal algorithm main loop.

So it was not impossible to write so small optimized code for several platforms. We just need to translate these 13 lines only.

All programs just print timings, it is written on the linked page with the results. Those emulators are capable to run tricky code for games and demos. So they are quite accurate. The only exception is the IBM PC emulator because timings were almost never a compatibility issue for this computer. There were too many variety of it that used different processors (the 8088, 8086, V20, V30, 80286, ...) at different clocks. So emulators for the IBM PC are usually faster than the original machines. IMHO the emulators just don't simulate the instruction queue delays. BTW if anybody knows the best IBM PC emulator please inform me about it.

It is possible just get machine cycles quantity for some processors (the Z80 and 6502) but requires different means to use and this IMHO can't change the results. And this approach misses the fine resulting pictures.


I can only claim that my code is optimized well but I can't claim it is perfect. The most difficult is the Z80 code optimization, it took about a month for me and I used help from several the Z80 experts. Finally I could speed up my initial Z80 code by about 50%. The other processors are more plain for optimizations. It would be great if somebody can discover the better code for the 6502 or other CPU.
It is interesting that for per MHz efficiency the 6502 beats the 8088 even on 16-bit calculations.

_________________
my blog about processors

Sarah Walker's PCem is cycle accurate, apparently.
https://retrocomputing.stackexchange.co ... 6-emulator

I like this emulator, I use it for the AT emulation. But to be cycle exact is not enough for the perfect IBM PC emulation because the x86 uses the instruction queue unit which can stop the main Central Processor Unit. This was documented very well by Michael Abrash. The instruction queue delays are especially significant for the 8088. Sorry I have been too lazy to do thorough checking of PCem sources, so I am not sure about the instruction queue emulation. But PCem IBM PC 5160 timings are faster than real iron too.

_________________
my blog about processors

I have ported the pi-spigot algorithm to the 6803. This CPU was used very rarely, I know only the Tandy TRS-80 MC-10 and its French clones. The results show that this processor is slightly faster than the 6809! It seems Motorola followed the DEC way to make processor instructions more complex and slow. The 6803 has faster instructions than the 6809 but the 6809 has more registers, instructions and addressing modes. However some instructions like LSRD or ASLD only exist for the 6803. If the 6803 also had ROLD, it would greatly speed up the division procedure for this processor.
It would also be interesting to guess how the 6502 might have evolved if MOS Technology had been regularly upgrading it. It is possible that they could have chosen the same path that Motorola did for the 6803. That would have meant using a 16-bit accumulator.

_________________
my blog about processors

I'm not surprising anyone here, but the ability to run legacy binaries was the constraint chosen for the '802 and '816, and they're full of 16-bit stuff behind those annoying mode bits. x86 followed a similar upgrade path, but threw much, much more money for R&D into the mix.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I have found out that the 6800 family consists of families of binary incompatible processors. I could count up to 5 families:
1) 6800/6802/6808, 6801/6803 (backward compatible with the 6800);
2) 6800, 68HC08;
3) 6800, 68HC11;
4) 6804, 6805;
5) 6809, 6309 (backward compatible with the CMOS 6809).
This is not a complete list. I am not able to finish it, too many controllers are there. The 6502 family is a set of more compatible processors. But it also contains varieties:
1) NMOS 6502 (undocumented instructions);
2) CMOS 6502 (almost 100% compatible with the NMOS 6502 without undocumented instructions);
3) 6509 (almost 100% compatible with the NMOS 6502);
4) 65CE02 (backward compatible with the CMOS 6502);
5) HuC6280 (backward compatible with the CMOS 6502?);
6) DTV (backward compatible with the CMOS 6502);
7) WDC65C02 (backward compatible with the CMOS 6502);
8 ) 65816 (backward compatible with the CMOS 6502).
It is interesting that almost universal assembler VASM has supports for all (?) 6502 8-bit varieties but still misses the 65816.

_________________
my blog about processors

I don't have any practical experience with it, but the 68HC12 looks like it would be my favorite cousin from that family. It lost the 6809/6309's U register, but in doing so gained an impressive amount of binary code efficiency with a carefully overhauled opcode matrix.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Wow, 30% smaller code is very impressive!