68kcounter - ASM cycle and size calculator

[KONEY]

The web version has some strange output, looks like some debug or something?

PHP Code:

{"statement":{"type":"","text":";============================================================================","loc":{"start":0,"end":77},"operands":[],"comment":{"type":"Comment","text":";============================================================================","loc":{"start":0,"end":77}}},"bytes":0,"bss":false} 


[DanScott]

that's JSON

[KONEY]

Of course, but looks like a debugging output. Is it supposed to be like this?

[gigabates]

Originally Posted by KONEY

Of course, but looks like a debugging output. Is it supposed to be like this?

No it's not! I accidentally committed some debugging code. Should be sorted now.

[KONEY]

it works, thanks! And thanks for the useful tool!

[roondar]

This is a very cool tool - extremely useful.
It can save me a lot of work for the optimisation phase!

In fact, the only possible major improvement I can see would be to be able to select CPU type (000/020/etc) as well

[gigabates]

Originally Posted by roondar

This is a very cool tool - extremely useful.
It can save me a lot of work for the optimisation phase!

In fact, the only possible major improvement I can see would be to be able to select CPU type (000/020/etc) as well

Thanks, I'm glad it's useful! I did look into other processor types and it would definitely be possible, but things do get more complicated.

From the MC68020UM:

The advanced architecture of the MC68020/EC020 makes exact instruction timing calculations difficult due to the effects of:
1. An On-Chip Instruction Cache and Instruction Prefetch
2. Operand Misalignment
3. Bus Controller/Sequence Concurrency
4. Instruction Execution Overlap
These factors make MC68020/EC020 instruction set timing difficult to calculate on a single instruction basis since instructions vary in execution time from one context to another.

It then goes on to list 3 values for each operation and address lookup: Best Case, Cache Case and Worst Case. The tool would ideally need to display all three. I'm also wondering if the misalignment and execution overlap factors could be determined from the context in the program.

[KONEY]

As a minor improvment I'd suggest some integration with github, like an url field which loads a piece of code from a repository

Originally Posted by roondar

In fact, the only possible major improvement I can see would be to be able to select CPU type (000/020/etc) as well

[roondar]

Originally Posted by gigabates

Thanks, I'm glad it's useful! I did look into other processor types and it would definitely be possible, but things do get more complicated.

From the MC68020UM:
It then goes on to list 3 values for each operation and address lookup: Best Case, Cache Case and Worst Case. The tool would ideally need to display all three. I'm also wondering if the misalignment and execution overlap factors could be determined from the context in the program.

The difficulty regarding misalignment is that you'd need to know exactly how the 68020 treats the various cases that can happen given that it prefetches 32 bits at a time. Determining starting alignment/misalignment is probably easy enough, but I'm not too sure what happens when you start looking at full instruction streams. My guess is that an initially aligned instruction, linear (no branching) instruction stream stays aligned even if parts of it might technically not be - due to the 32 bit prefetch. But that's just a guess and I'm not so sure what happens when you jump/branch to non-aligned words.

To me, this all sounds tricky, but perhaps you or someone else here has some shortcuts/methods that make it easier.

Instruction overlap is even more tricky, as the initial workings of the 68020 regarding this are not properly/fully documented by Motorola or anyone else (there is something in the user manual, but I'm pretty sure those examples are just the tip of the iceberg in terms of what can and can't happen). I'd personally suggest leaving this out altogether, getting a reasonable baseline count is worthwhile on it's own even if it may miss out on the overlap advantages.


Anyway, I'd honestly already be very happy with a cycle counter that shows best/cache/worst cases for 68020+. I'd be even happier with one that allows me to specify the worst case cycle speed penalty (as this is fully dependent on memory speed and A1200 chip memory is quite slow)

[Rock'n Roll]

very good tool, but if I want find an optimization for a mulu, muls
I get a range of cycles. It could be optimized.
(thats only a suggestion for improvement)

70 is max time. Motorola documentation only list max time for any instruction that has variable timing.

Code:
MULS, MULU — The multiply algorithm requires 38+2n clocks where n is defined as:
MULU: n = the number of ones in the <ea>
MULS: n=concatenate the <ea> with a zero as the LSB; n is the resultant number of 10
or 01 patterns in the 17-bit source; i.e., worst case happens when the source is $5555.

mul:			cycles		n
	move.l  #0,d0					12(3/0)
	move.l  #0,d1					12(3/0)
	mulu	d0,d1	; 38		 0		38(1/0) 70(1/0)
	move.l  #1,d0
	move.l  #0,d1	
	mulu	d0,d1	; 40		 1
	move.l  #2,d0
	move.l  #0,d1	
	mulu	d0,d1	; 40		 10
	move.l  #3,d0
	move.l  #0,d1	
	mulu	d0,d1	; 42		 11

Total cycles:
248(28/0) – 376(28/0)

[gigabates]

Yeah it does give exact cycle counts using the correct algorithm when multiplying by immediate values. What it can't currently do is know what value is in a given register like in your example. It would essentially have to execute the code to know this. For now it gives a range in this case.