68000 code optimisations

[Gunnar]

Originally Posted by britelite

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.

[britelite]

Originally Posted by Gunnar

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

Can it run 68060 code?

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.

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.

[Apollo]

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.

[Thorham]

Originally Posted by Gunnar

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.

Originally Posted by Apollo

IMHO this gets more and more into an advertising feature.

Indeed.

[Gunnar]

Originally Posted by Thorham

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.

[britelite]

Originally Posted by Gunnar

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.

[Vot]

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..

[StingRay]

Originally Posted by Apollo

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.

Originally Posted by Apollo

So I subscribe to the suggestion above: put the Vampire600 related optimizations into a separate thread.

[britelite]

On the 68000, is there a faster way of getting the high bytes of two words into one word than doing:

move.w d0,d2
move.w d1,-(sp)
move.b (sp)+,d2

A lookuptable is not an option.

[TCD]

OT 'discussion' removed. Open a new thread if you think the topic is worth it.

[Photon]

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.

[meynaf]

Methinks that the best optimizations are the ones that work everywhere.

Like this :

 tst.w d0
 bmi out
 tst.w d1
 bmi out
 cmpi.w #maxx,d0
 bge out
 cmpi.w #maxy,d1
 bge out

replaced by :

 cmpi.w #maxx,d0
 bhs out
 cmpi.w #maxy,d1
 bhs out

[TheDarkCoder]

Originally Posted by Photon

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.

[PeterJ]

cool thread, but i think that i need to reread a couple of times

[NorthWay]

Originally Posted by frank_b

       move.b  d0,-(sp)
       move.w (sp)+,d0  ; magic fast shift :)

As has been pointed out, alternative version:

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

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

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.

[StingRay]

Originally Posted by NorthWay

Set an address register to 0 and you can use a full 32-bit data register as a pointer with sth like

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:

move.b address,d1

?

[britelite]

Originally Posted by NorthWay

Align data structures to 64K

add.l #$0000ffff,d0
and.l #$ffff0000,d0

And considering this topic is about optimizations, this one is smaller and faster:

add.l #$0000ffff,d0
clr.w d0

[NorthWay]

Originally Posted by StingRay

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.

[meynaf]

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) :

 move.w d0,d1
 subq.w #1,d1
 and.w d1,d0

To know if the n leftmost bits of the reg are identical :

 asl.b #n-1,d0		; note : asl, not lsl !
 bvc yes		; we get there if all bits were the same

[meynaf]

I forgot about this one...


You can replace :

 not.l d1              ; reverse mask
 and.l d1,d0           ; clear bits that were '1'
 not.l d1              ; restore mask

by :

 or.l d1,d0            ; set these bits to '1'
 eor.l d1,d0           ; then clear them