68000 code optimisations

[Gunnar]

Originally Posted by NorthWay

Use movep to get a byte to the upper half of a word.

A series of subrutine(OS?) calls like
jsr sub1
jsr sub2
jsr sub3
rts

can be turned on the head as
pea sub3
pea sub2
jmp sub1

optionally push the continue address first. I did this for my Exec optimizes.

While this is OK for an old 68000 doing this is bad for new chips.

Modern Cores which have a linkstack will run the original code
jsr sub1
jsr sub2
jsr sub3
rts

Much faster.

[Photon]

Remove the rts and make the last jsr a jmp.

[meynaf]

Originally Posted by Gunnar

While this is OK for an old 68000 doing this is bad for new chips.

Provided there will be new chips at all

Originally Posted by Gunnar

Modern Cores which have a linkstack will run the original code
jsr sub1
jsr sub2
jsr sub3
rts

Much faster.

Much faster ? Not necessarily. After the first RTS is seen and the linkstack is found to be obsolete, i think the linkstack will/should somehow readjust itself and then run at full speed for subsequent RTS.

Anyway if you have lots of JSR/RTS in your critical path, you're doing something wrong

[Gunnar]

Originally Posted by meynaf

Provided there will be new chips at all


Much faster ? Not necessarily. After the first RTS is seen and the linkstack is found to be obsolete, i think the linkstack will/should somehow readjust itself and then run at full speed for subsequent RTS.

Anyway if you have lots of JSR/RTS in your critical path, you're doing something wrong

Apollo needs 2 cycles for a BSR and 2 cycles for a RTS (hitting the Linkstack)
The BSR and RTS can be executed in parallel with another instructions in this cycle. (Not on the Vampire600 as the SS is of here because of FPGA size :-( )
This means the 2 cycle subroutine overhead is not much.

[meynaf]

And how many clocks does it take for a missed linkstack ?

[Photon]

Originally Posted by Gunnar

Apollo needs 2 cycles for a BSR and 2 cycles for a RTS (hitting the Linkstack)
The BSR and RTS can be executed in parallel with another instructions in this cycle. (Not on the Vampire600 as the SS is of here because of FPGA size :-( )
This means the 2 cycle subroutine overhead is not much.

Define what you mean by "Apollo", "Vampire600", and "Modern core".

[Gunnar]

Originally Posted by Photon

Define what you mean by "Apollo", "Vampire600", and "Modern core".

Apollo = http://www.apollo-core.com

Vampire 600 = http://www.majsta.com

Modern Core = see Apollo

[matthey]

Originally Posted by Photon

Remove the rts and make the last jsr a jmp.

I hope so. I've been using this optimization everywhere I can as rts is slow without a link stack. I believe this optimization would be good even with a link stack and on all of the 68k family.

To be clear, optimize this:

   jsr sub1
   jsr sub2
   jsr sub3
   rts

to this:

   jsr sub1
   jsr sub2
   jmp sub3

Many assemblers like vasm can optimize the jsr->bsr and jmp->bra saving more cycles when possible.

[Thorham]

Shouldn't you inline those subroutines to get rid of the function call overhead?

[Mrs Beanbag]

Originally Posted by Thorham

Shouldn't you inline those subroutines to get rid of the function call overhead?

depending on how big they are

[NorthWay]

Originally Posted by Thorham

Shouldn't you inline those subroutines to get rid of the function call overhead?

Sometimes those functions are in fact OS calls, and even if the OS itself can do an internal call I don't like it and think it is messy.

You can always do the tail optimize though.

[Thorham]

Originally Posted by Mrs Beanbag

depending on how big they are

Is that relevant? You'd only inline larger functions when the code is more or less finished. Keep a tidy reference version, and do a messy optimized version based on that.

Originally Posted by NorthWay

Sometimes those functions are in fact OS calls

But what are OS calls doing in tight loops?

[Mrs Beanbag]

Originally Posted by Thorham

Is that relevant? You'd only inline larger functions when the code is more or less finished. Keep a tidy reference version, and do a messy optimized version based on that.

you wouldn't want a large function copied umpty times in your code, besides the saving in terms of cycles compared to the time spent in the function wouldn't be worth the mess.

[Thorham]

Originally Posted by Mrs Beanbag

you wouldn't want a large function copied umpty times in your code

But how many different tight loops of 100000+ iterations are going to call the same large function?

Originally Posted by Mrs Beanbag

the mess

That's why you keep a tidy reference version. It's the version that's done, except for optimizations which will be messy. You copy that, and make a mess in the copy. Inlining also means there's an opportunity to optimize more than just the function call. Depends on the code if it's worth it or not.

[Photon]

Originally Posted by Gunnar

Apollo = http://www.apollo-core.com

Vampire 600 = http://www.majsta.com

Modern Core = see Apollo

Please refrain from posting about nextgen here. Use the dedicated forum I created for that purpose.

Optimizations here should be based only on features present in legacy Motorola CPUs, or there will be confusion.

In a way, even within the 680x0, optimizations become more pointless the better the features. Caches take care of a lot, the CPU is already fast for what you can do with the rest of the Amiga, and so on.

The best optimizations are general-purpose with a specific gain. If the gain "umm... it depends", it's more likely a niche use that not a lot of coders will have occasion to find a use for.

[Gunnar]

Originally Posted by Photon

Please refrain from posting about nextgen here. Use the dedicated forum I created for that purpose.

Apollo/Phoenix is a member of 68K-family just like the 68040 or 68060.

[britelite]

Originally Posted by Gunnar

Apollo/Phoenix is a member of 68K-family just like the 68040 or 68060.

But he said "legacy Motorola CPU", which the Apollo/Phoenix is not.

EDIT: And considering the topic is "68000 code optimisations", I'd be interested in actually reading about 68000 tricks, not stuff for the later CPUs.

[Gunnar]

Originally Posted by britelite

EDIT: And considering the topic is "68000 code optimisations", I'd be interested in actually reading about 68000 tricks, not stuff for the later CPUs.

Maybe you should re-read my post:
I did not post optmization tricks for another CPU than 68000.
I only pointed out that trick XYZ works good on 68000 but has a drawback on another 68K CPU.

The same way you can say using MOVEP on 68000 might save some cycles,
but can have a huge penalty on an 68060 system.

Pointing out side effects for other 68K cores is good and helps coders.

[britelite]

Originally Posted by Gunnar

I did not post optmization tricks for another CPU than 68000.

Could be, I mainly reacted to your response to Photon. And he reacted to a post where you specifically wrote about the Apollo/Phoenix.

[StingRay]

Originally Posted by Gunnar

Maybe you should re-read my post:
I did not post optmization tricks for another CPU than 68000.
I only pointed out that trick XYZ works good on 68000 but has a drawback on another 68K CPU.

Maybe you should re-read what Photon wrote, he certainly has a good reason for that.

Originally Posted by Gunnar

The same way you can say using MOVEP on 68000 might save some cycles,
but can have a huge penalty on an 68060 system.

And this thread is about 68040/60 optimisations since when?