68kcounter - ASM cycle and size calculator

[gigabates]

I've built a tool to calculate cycle and size information from 68k ASM source. Currently it's available as a web app and an NPM package with CLI tool. Eventually I'd like to make a VSCode extension for editor integration. I'm pretty new to ASM and I've based the implementation on the available documentation as far as possible. I'd be interested to see:

• Whether it's useful to anyone else
• How accurate it is if anyone more knowledgable can verify

Thanks!

[Cyprian]

nice tool, would be cool to have sum of all cycles (also without selecting a range)

[roondar]

That's pretty cool. I'll be sure to check it out!

[gigabates]

Originally Posted by Cyprian

nice tool, would be cool to have sum of all cycles (also without selecting a range)

Thanks! I initially included that but I disabled it as I thought it was a bit confusing. I was thinking that total cycles across a whole file doesn't really make sense due to branching, loops etc. and I imagined it would only be useful for continuous blocks of instructions. I'll put it back if it's useful.

[Rock'n Roll]

WinUAE Debugger can calculate the cycle and bus usage.

start:
	move.w #$4000,$dff09a	; Interrupts disable
waitmouse:  
	btst	#6,$bfe001		; left mousebutton?
	bne.s	Waitmouse	

	lea	Table,a0			; 12 cycles
	move.w	#1200-1,d7		; 8 cycles
CleaLoop:
	clr.b	(a0)+			; 12 cycles
	dbne	d7,CleaLoop		; 10 cycles (+14 false)
	nop	
	move.w #$C000,$dff09a	; Interrupts enable
	rts

Table:
	blk.w 1200,$FFFF		
	end

bad sample programm - only for demonstration
start 12+8=20 cycles , clr.b 1200 * 12 = 14400 cycles
dbne 1199 * 10 = 11990 cycles, dbne (false) 14 cycles
sum = 20 + 14400 + 11990 + 14 = 26424

1. first assemble the programm and run
2. programm waits now for left mousebutton
3. Shift+F12 opens the debugger
4. make d PC - shows the disassembled program
5. f adress - set breakpoint on line lea table,a0
6. x - leave debugger
7. press left mousebutton - reopens the debugger
8. fi nop (WinUAE 4.5) or fi 4E71 - step forward until nop
9. now you can see all cycles
10. x - leave the debugger
11. (with t and t number - you can step one or more instructions)

>d PC
00027638 0839 0006 00bf e001      BTST.B #$0006,$00bfe001
00027640 66f6                     BNE.B #$f6 == $00027638 (T)
00027642 41f9 0002 765e           LEA.L $0002765e,A0
00027648 3e3c 04af                MOVE.W #$04af,D7
0002764C 4218                     CLR.B (A0)+ [ff]
0002764E 56cf fffc                DBNE.W D7,#$fffc == $0002764c (T)
00027652 4e71                     NOP
00027654 33fc c000 00df f09a      MOVE.W #$c000,$00dff09a
0002765C 4e75                     RTS
0002765E ffff                     ILLEGAL
>f 27642
Breakpoint added.
>x

now press left mouse button - debugger reopens

>fi nop (or fi 4E71)
Cycles: 13212 Chip, 26424 CPU. (V=0 H=34 -> V=58 H=80)
D0 00000000 D1 00000000 D2 00000000 D3 00000000
D4 00000000 D5 00000000 D6 00000000 D7 0000FFFF
A0 00027B0E A1 00000000 A2 00000000 A3 00000000
A4 00000000 A5 00000000 A6 00000000 A7 00C60DB0
USP 00C60DB0 ISP 00C61DB0
T=00 S=0 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=0 STP=0
Prefetch 4e71 (NOP) 33fc (MOVE) Chip latch 00000000
00027652 4e71 NOP
Next PC: 00027654
>x

Toni:
in my opinion it would be better to rename following commands:
f - f <address> Add/remove breakpoint. --> b
fl - fl List breakpoints. --> bl
fd - fd Remove all breakpoints. --> bd
That makes more sense and the next point ist there are a lot of f - commands.

[Cyprian]

Originally Posted by Rock'n Roll

WinUAE Debugger can calculate the cycle and bus usage.

yep, also Steem and Hatari offer great 68k cycle calculations (I know, different platform) but gigabates' tool is good complement to these tools. We can paste the code quickly and see cycles.

[gigabates]

I've now created a VS Code extension which provides live annotations on your code as you type.

[JoeJoe]

@gigabates: NICE ONE! The extension works fine with label too.

Same lines with different cycles.

[kamelito]

Suggestions from Twitter:
1) One idea that comes to mind, is to have the tool automatically suggest (as comments) faster alternatives, like if you type "move.l #8,d0" it would show the clock cycles that takes, but point out that "moveq" would do the same faster

2) Pushing the idea further, it would be useful for beginners to actually show the details of where the cycles come from, like fetching of the instruction, plus memory accesses, addressing mode, internal computations (like the 2n cycles for rotates or the mul/div).
3) Interesting, but to be useful to me it needs to get two improvements:
- it needs to actually recognize "nop"
- on the Atari ST clock cycles are rounded to multiple of 4 due to the way the bus is accessed, so this EXG would take 8 cycles instead of 6 in most situations.

[Cyprian]

Originally Posted by kamelito

3) Interesting, but to be useful to me it needs to get two improvements:
- it needs to actually recognize "nop"
- on the Atari ST clock cycles are rounded to multiple of 4 due to the way the bus is accessed, so this EXG would take 8 cycles instead of 6 in most situations.

on the ST is observable so called 'instruction pairing' where e.g. two 6 instructions take together 12 cycles instead of 16 (8+8) after rounding.

http://pasti.fxatari.com/68kdocs/Ata...eCounting.html

[tolkien]

Damn! This extension seems great. It a shame I use a private asm extension and seems it is not compatible with this one.

I get this error:

El comando "68kcounter: Count selection" dio lugar a un error (command '68kcounter.countSelection' not found)

[gigabates]

Originally Posted by tolkien

Damn! This extension seems great. It a shame I use a private asm extension and seems it is not compatible with this one.

I get this error:

El comando "68kcounter: Count selection" dio lugar a un error (command '68kcounter.countSelection' not found)

It should be pretty trivial to get this working with your extension. My extension gets activated based on the language of the active document. This is what it looks for in order to support a few different implementations:

    "onLanguage:m68k",
    "onLanguage:amiga-assembly-debug.disassembly",
    "onLanguage:as",
    "onLanguage:vasmmot",
    "onLanguage:vasmstd",
    "onLanguage:codewarrior"

If you let me know what language name your extension uses I can add it to the list.

[gigabates]

Originally Posted by Cyprian

on the ST is observable so called 'instruction pairing' where e.g. two 6 instructions take together 12 cycles instead of 16 (8+8) after rounding.

http://pasti.fxatari.com/68kdocs/Ata...eCounting.html

I was just reading up on this. It would be pretty simple to add an 'Atari mode' which follows the 'Round up to a multiple of four' rule, but it gets more complicated when it comes to the pairing/alignment stuff. Am I right in thinking there would be no way to know how the instructions align with bus cycles from the pre-assembled source?

[gigabates]

Originally Posted by kamelito

Suggestions from Twitter:
1) One idea that comes to mind, is to have the tool automatically suggest (as comments) faster alternatives, like if you type "move.l #8,d0" it would show the clock cycles that takes, but point out that "moveq" would do the same faster

2) Pushing the idea further, it would be useful for beginners to actually show the details of where the cycles come from, like fetching of the instruction, plus memory accesses, addressing mode, internal computations (like the 2n cycles for rotates or the mul/div).
3) Interesting, but to be useful to me it needs to get two improvements:
- it needs to actually recognize "nop"
- on the Atari ST clock cycles are rounded to multiple of 4 due to the way the bus is accessed, so this EXG would take 8 cycles instead of 6 in most situations.

Thanks a lot for sharing and providing feedback.

1) I'd also thought about this and it's something I'd like to explore. To me it seems like there are two categories of suggestions. There are the ones where the result is exactly equivalent and are probably already applied by your assembler. I could probably have a look at what rules vasm follows. There are others where they might be equivalent depending on your use case e.g. whether you rely on the CCR. This sounds like it could end up like a linter tool, which would certainly make an interesting project.

2) This shouldn't be hard to do. I might give it a go.

3) Lack of NOOP support was a bug in my timing table. I've since fixed this along with a couple of others.

[gigabates]

Originally Posted by JoeJoe

@gigabates: NICE ONE! The extension works fine with label too.

Same lines with different cycles.

Thanks!
Is 'SP' a valid synonym for a7 in addition to 'SR' or is this a typo? What's happening here is that it defaults to interpreting '-(SP)' as an absolute address as it doesn't match any other known patterns.

edit: Ignore me, I'm an idiot!

[Jobbo]

I tried this with Bartman's GCC setup and it didn't work.

I think you need to add language modes: amiga.assembly and amiga.disassembly

[roondar]

Originally Posted by gigabates

Thanks!
Is 'SP' a valid synonym for a7 in addition to 'SR' or is this a typo? What's happening here is that it defaults to interpreting '-(SP)' as an absolute address as it doesn't match any other known patterns.

Yeah, SP is a synonym for a7.

[gigabates]

Originally Posted by Jobbo

I tried this with Bartman's GCC setup and it didn't work.

I think you need to add language modes: amiga.assembly and amiga.disassembly

Ok it should work now. I just pushed an update that activates on amiga.disassembly (amiga.assembly didn't seem to exist), but more importantly it also activates when you run either either of the commands: '68kcounter: Toggle counts' or '68kcounter: Count selection' on any file regardless of language. This is what it should have done all along but I'm a bit of a VS Code extension n00b!

[gigabates]

Originally Posted by roondar

Yeah, SP is a synonym for a7.

Argh, of course it is! The typo was in my source code and even after reading it I switched them around in my head and convinced myself that 'SR' was a thing!


Fix incoming...

[Jobbo]

That works but it would be nice to have the little icon to click.

amiga.assembly must be part of Bartman's extension.

I don't have any of the other ones you mentioned because I don't have those other extensions that are exclusively for assembly only.

What do the different colors for your output indicate?