05 June 2014, 16:44 | #101 | |
Registered User
Join Date: Apr 2014
Location: Germany
Posts: 154
|
Quote:
Modern Cores which have a linkstack will run the original code jsr sub1 jsr sub2 jsr sub3 rts Much faster. |
|
06 June 2014, 01:01 | #102 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,660
|
Remove the rts and make the last jsr a jmp.
|
09 June 2014, 08:35 | #103 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
Quote:
Anyway if you have lots of JSR/RTS in your critical path, you're doing something wrong |
||
09 June 2014, 08:57 | #104 | |
Registered User
Join Date: Apr 2014
Location: Germany
Posts: 154
|
Quote:
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. |
|
09 June 2014, 09:10 | #105 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
And how many clocks does it take for a missed linkstack ?
|
09 June 2014, 19:39 | #106 | |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,660
|
Quote:
|
|
09 June 2014, 20:51 | #107 | |
Registered User
Join Date: Apr 2014
Location: Germany
Posts: 154
|
Quote:
Vampire 600 = http://www.majsta.com Modern Core = see Apollo |
|
09 June 2014, 22:13 | #108 |
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
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: Code:
jsr sub1 jsr sub2 jsr sub3 rts Code:
jsr sub1 jsr sub2 jmp sub3 |
09 June 2014, 22:29 | #109 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,852
|
Shouldn't you inline those subroutines to get rid of the function call overhead?
|
09 June 2014, 22:44 | #110 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
|
09 June 2014, 22:53 | #111 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
|
09 June 2014, 23:20 | #112 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,852
|
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.
But what are OS calls doing in tight loops? |
09 June 2014, 23:34 | #113 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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.
|
10 June 2014, 01:53 | #114 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,852
|
Quote:
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. |
|
10 June 2014, 22:34 | #115 | |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,660
|
Quote:
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. |
|
11 June 2014, 07:01 | #116 |
Registered User
Join Date: Apr 2014
Location: Germany
Posts: 154
|
|
11 June 2014, 07:11 | #117 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 821
|
Quote:
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. Last edited by britelite; 11 June 2014 at 07:22. |
|
11 June 2014, 07:36 | #118 | |
Registered User
Join Date: Apr 2014
Location: Germany
Posts: 154
|
Quote:
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. |
|
11 June 2014, 07:41 | #119 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 821
|
|
11 June 2014, 07:53 | #120 | |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
Quote:
And this thread is about 68040/60 optimisations since when? |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
68000 boot code | billt | Coders. General | 15 | 05 May 2012 20:13 |
Wasted Dreams on 68000 | sanjyuubi | support.Games | 5 | 27 May 2011 17:11 |
680x0 to 68000 | Counia | Hardware mods | 1 | 01 March 2011 10:18 |
quitting on 68000? | Hungry Horace | project.WHDLoad | 60 | 19 December 2006 20:17 |
3D code and/or internet code for Blitz Basic 2.1 | EdzUp | Retrogaming General Discussion | 0 | 10 February 2002 11:40 |
|
|