English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 11 June 2014, 09:06   #121
Gunnar
Registered User

 
Join Date: Apr 2014
Location: Germany
Posts: 154
Quote:
Originally Posted by britelite View Post
And he reacted to a post where you specifically wrote about the Apollo/Phoenix.
Apollo/Phoenix is an 68K core which you code with pure 68K assembly.
You can use your old SEKA or AsmONE to code it.
The core runs original 68k programs natively.

The Vampire600 is an existing CPU Turbocard for the Amiga 600, which is a classic machine. This turbo card comes with 64 MB fastmem and an 68K CPU somewhat in the performance range of overclocked 68060.
And this for a price of only €90.

The Phoenix core can outperform 68060 and this for a fraction of the price.

New, faster CPU cards coming out with APOLLO-Phoenix-68K Cores,
not only for A600 but also for mostly all other classic OCS/ECS/AGA AMIGA models.

People will soon have the choice to buy for the same money a 68020 CPU card, or a Phoenix card with 128MB memory and a CPU performance in the order on an 100 MHz 68060.

You do not have to be smart to foresee how the distribution of 68K cores could look like in a few month.

Its not unlikely that soon many classic AMIGA users will have a 200 MIPS 68K CPU. This can also change the software landscape as much more software can then be used fluently on 68K machines.

With this in mind - I think pointing out "coding clues" and options for Phoenix makes sense - as it might be of relevance for many of the forum users very soon.
Gunnar is offline  
Old 11 June 2014, 09:10   #122
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 618
Quote:
Originally Posted by Gunnar View Post
The Phoenix core can outperform 68060 and this for a fraction of the price.
Can it run 68060 code?

Quote:
Its not unlikely that soon many classic AMIGA users will have a 200 MIPS 68K CPU. This can also change the software landscape as much more software can then be used fluently on 68K machines.
Maybe, maybe not.

Quote:
With this in mind - I think pointing out "coding clues" and options for Phoenix makes sense - as it might be of relevance for many of the forum users very soon.
You can start a new thread for these "coding clues". In a 68000 specific thread they're not relevant. If there are any issues using 68000 code on the Apollo/Phoenix it's your problem, not the coders.
britelite is online now  
Old 11 June 2014, 13:04   #123
Apollo
Registered User

Apollo's Avatar
 
Join Date: Sep 2008
Location: Germany
Age: 45
Posts: 127
IMHO this gets more and more into an advertising feature. I always understood this thread for code optimizations on the plain 'ol 68ooo, the "classic" Amiga platform. I count myself to the handful coders which are mainly interested in coding for this, for whatever reasons.
So I subscribe to the suggestion above: put the Vampire600 related optimizations into a separate thread.
Apollo is offline  
Old 11 June 2014, 13:06   #124
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,086
Quote:
Originally Posted by Gunnar View Post
With this in mind - I think pointing out "coding clues" and options for Phoenix makes sense - as it might be of relevance for many of the forum users very soon.
Wrong thread, this thread is about 68000, not FPGA processors.

Quote:
Originally Posted by Apollo View Post
IMHO this gets more and more into an advertising feature.
Indeed.
Thorham is offline  
Old 11 June 2014, 13:11   #125
Gunnar
Registered User

 
Join Date: Apr 2014
Location: Germany
Posts: 154
Quote:
Originally Posted by Thorham View Post
Wrong thread, this thread is about 68000, not FPGA processors.
Nonsense.
This thread is about tuning on 68000.

Whether the 68000 an ASIC or an FPGA is irrelevant.
Both can be 100% the same.
Gunnar is offline  
Old 11 June 2014, 13:28   #126
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 618
Quote:
Originally Posted by Gunnar View Post
Whether the 68000 an ASIC or an FPGA is irrelevant.
Both can be 100% the same.
Sure, both CAN be 100% the same. But this doesn't seem to be the case here.
britelite is online now  
Old 11 June 2014, 13:33   #127
Vot
Registered User

 
Join Date: Aug 2012
Location: Australia
Posts: 648
Gunnar,

If the cores are so fast for so cheap why all the talk in the other thread about fpga size? Why not use a bigger more expensive fpga. Given the performance your stating I would be happy to pay a little more if it means you could cram everything you want into the core..
Vot is offline  
Old 11 June 2014, 13:36   #128
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,291
Quote:
Originally Posted by Apollo View Post
IMHO this gets more and more into an advertising feature.
Color me unsurprised, as I already wrote in another thread some weeks ago: I have a slight feeling of Déjà-vu as this is not the first time this has happened.

Quote:
Originally Posted by Apollo View Post
So I subscribe to the suggestion above: put the Vampire600 related optimizations into a separate thread.
StingRay is offline  
Old 11 June 2014, 14:51   #129
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 618
On the 68000, is there a faster way of getting the high bytes of two words into one word than doing:

Code:
move.w d0,d2
move.w d1,-(sp)
move.b (sp)+,d2
A lookuptable is not an option.
britelite is online now  
Old 11 June 2014, 14:56   #130
TCD
Registered User

TCD's Avatar
 
Join Date: Sep 2006
Location: Germany
Age: 41
Posts: 24,012
OT 'discussion' removed. Open a new thread if you think the topic is worth it.
TCD is offline  
Old 11 June 2014, 19:19   #131
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,805
Gunnar, Natami and other excellent projects are admirable, but this forum is specifically for the original hardware. That's basically all that the "refrain from" etc. was about

pea and movep slow down 68040 and 68060 unnecessarily, and don't gain much even on 68000. So far the advice is good, even if I think this thread is almost only useful for learning how to save cycles on the slower Motorola CPUs.

Because the optimization techniques here *do* save cycles on slow CPUs, it's counterproductive to suggest (in this forum, that is) that we shouldn't optimize because a modern core will run it faster than a 68060 if we don't.
Photon is offline  
Old 12 June 2014, 10:28   #132
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,644
Methinks that the best optimizations are the ones that work everywhere.

Like this :
Code:
 tst.w d0
 bmi out
 tst.w d1
 bmi out
 cmpi.w #maxx,d0
 bge out
 cmpi.w #maxy,d1
 bge out
replaced by :
Code:
 cmpi.w #maxx,d0
 bhs out
 cmpi.w #maxy,d1
 bhs out
meynaf is online now  
Old 12 June 2014, 12:45   #133
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Quote:
Originally Posted by Photon View Post
Gunnar, Natami and other excellent projects are admirable, but this forum is specifically for the original hardware. That's basically all that the "refrain from" etc. was about
Yes, please, Gunnar and others are discussing FPGA related stuff in other, very interesting threads. I think this specific thread should be restricted to the "68000 family" as defined by Motorola.

Also, IMHO, this thread should be devoted to very specific questions about instruction-level optimizations. More hi-level optimizations such as inlining functions or algorithms for doing stuff like c2p (all very interesting subjects) are better placed in other threads. In this way, it is easier to search in the thread.
TheDarkCoder is offline  
Old 18 February 2015, 03:27   #134
PeterJ
Registered User

 
Join Date: Feb 2015
Location: Copehagen
Posts: 36
cool thread, but i think that i need to reread a couple of times
PeterJ is offline  
Old 23 September 2015, 17:54   #135
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 618
Quote:
Originally Posted by frank_b View Post
Code:
       move.b  d0,-(sp)
       move.w (sp)+,d0  ; magic fast shift :)
As has been pointed out, alternative version:

Code:
move.w #$0000,-(sp) ;select your 00xx value here
...
move.b d0,(sp)
move.w (sp),d0
You can move the initial value setting outside any loop as long as you undo it at the end of your program. I used a version of it for my 6502 emulator.

Align data structures to 64K
Code:
add.l #$0000ffff,d0
and.l #$ffff0000,d0
Any sort of 8-bit cpu emulator can then be addressed by 16-bit numbers if you leave the upper 16 of your data register alone and combine it with:

Set an address register to 0 and you can use a full 32-bit data register as a pointer with sth like
Code:
sub.l a0,a0
move.l #address,d0
move.b (a0,d0.l),d1
Using bitmap and blitter data aligned in 64K chunks can let you only update lower words instead of the full address.
NorthWay is offline  
Old 24 September 2015, 08:33   #136
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,291
Quote:
Originally Posted by NorthWay View Post
Set an address register to 0 and you can use a full 32-bit data register as a pointer with sth like
Code:
sub.l a0,a0
move.l #address,d0
move.b (a0,d0.l),d1
Maybe I'm missing something obvious but why do it like this when this does the same:

Code:
move.b address,d1
?
StingRay is offline  
Old 24 September 2015, 08:57   #137
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 618
Quote:
Originally Posted by NorthWay View Post
Align data structures to 64K
Code:
add.l #$0000ffff,d0
and.l #$ffff0000,d0
And considering this topic is about optimizations, this one is smaller and faster:

Code:
add.l #$0000ffff,d0
clr.w d0
britelite is online now  
Old 24 September 2015, 10:59   #138
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 618
Quote:
Originally Posted by StingRay View Post
Maybe I'm missing something obvious but why do it like this when this does the same:
It was just a loose, fast and bad example of using it.
The real use is when you do pointer math.

And that clr.w is ofc much better.
NorthWay is offline  
Old 25 September 2015, 14:41   #139
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,644
A few more tricks...
For rare cases but useful maybe ?


Clear the lowest bit that is =1 (e.g. $1234 becomes $1230, $1000 becomes 0, etc) :
Code:
 move.w d0,d1
 subq.w #1,d1
 and.w d1,d0

To know if the n leftmost bits of the reg are identical :
Code:
 asl.b #n-1,d0		; note : asl, not lsl !
 bvc yes		; we get there if all bits were the same
meynaf is online now  
Old 23 December 2015, 10:49   #140
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,644
I forgot about this one...


You can replace :
Code:
 not.l d1              ; reverse mask
 and.l d1,d0           ; clear bits that were '1'
 not.l d1              ; restore mask
by :
Code:
 or.l d1,d0            ; set these bits to '1'
 eor.l d1,d0           ; then clear them
meynaf is online now  
 


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 21:13
Wasted Dreams on 68000 sanjyuubi support.Games 5 27 May 2011 18:11
680x0 to 68000 Counia Hardware mods 1 01 March 2011 11:18
quitting on 68000? Hungry Horace project.WHDLoad 60 19 December 2006 21:17
3D code and/or internet code for Blitz Basic 2.1 EdzUp Retrogaming General Discussion 0 10 February 2002 12:40

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 13:56.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09965 seconds with 14 queries