Do you approve of PPC (in some form) as the future of Amiga?

[koaftder]

I'm happy with MorphOS on the mac and for x86 there's AROS, so I don't care either way. Next Amiga purchase will be a power mac and another MOS license. I'll use the machine until the wheels fall off and from having a bunch of mac PPC machines experience tells me that will be at least 10 years. I still have a working B&W G3 from '99 that's still kicking along. PPC Mac gear was built to last. I'm sure the MOS team will find a way to keep the ball rolling before the mac gear becomes useless.

[jorkany]

A little OT, but a major patch was released for World of Warcraft earlier this week. Support for PPC Macs has been dropped.

Here's the official notice warning up the change:
http://forums.worldofwarcraft.com/thread.html?topicId=26560499428&postId=265579704371&sid=1#0

[matthey]

This example isn't really good at anything other than demonstrating the 68K is forgiving of lazy programmers.

It's not just lazy programmers. Good programmers mess up simple loops too. The above code is excellent for aligned data on the 68060 and small unaligned copies. This will also be the case for the N68050+. This code can be inlined because it's so small saving even more. Most processors require the unrolled loop and are very particular about alignment. Get it wrong and performance is a fraction of what it could be. The 68060 and N68050+ are just as fast if you use the unrolled loop and in some cases will be a little bit faster if you align the data. Use a movem.l copy loop and there is very little slow down too. Code optimized for any 68k processor will run very well on the 68060 and N68k. Is forgiving, easy to program, and small code bad?

The alignment is never an unknown property;

Check out exec.library/CopyMem(). It will copy memory of any alignment. This function is used way more than exec.library/CopyMemQuick() which does longword aligned copies.  Never say never .

all you need to do is test the least significant bit(s) of the source and destination operands. You can also test the count and build a nice duff's device loop in assembler and only handle the trailing bytes before and after. On the 060, you might even be able to use move16, under the right circumstances; even when source and destination is not 16-byte aligned, you can often read (or write) via a temporary cache line in an appropriately aligned bit of stack.

Duff's device loop is slower on the 68060. Modern processors don't like the unpredictable jmp statement this generates and the 68060 doesn't need an unrolled loop. This is what the old SAS/C copy routine uses though. Does it perform poorly on the 68060? Not too bad. Are you a lazy programmer because you chose a slower copy routine that is ten times bigger? Nope. You're covered because the 68k is forgiving .

You are right about testing the least significant bits to align the data except you only need to align the destination.  Reading unaligned data is not as bad as writing unaligned data. Move16 is barely worth it on the Amiga at all. You have to copy several thousand bytes to make it worthwhile. Copies this large are rare on 68k Amigas. Here is a patch I wrote for CopyMem() and CopyMemQuick() on the 68060 and 68040...

http://aminet.net/util/boot/CopyMem.readme (readme)
http://aminet.net/util/boot/CopyMem.lha

It has assembler sources, timings, a Snoopy script that will show you the sizes and alignments of CopyMem() and CopyMemQuick() copies and more info. The 68060 optimized code is only 35% faster than the AmigaOS 3.9 functions which use a poorly implemented movem.l loop. They should have used an unrolled loop for the best performance on 68020-68060 and considering most copies are small. More lazy programmers?.

[Heiroglyph]

While I agree that the 68060 was a great CPU, there is a point where brute force and momentum overcome elegance.

I like the idea of using 680x0 code as a sort of bytecode JIT like Java or .net does.

It would give the ease of programming and backwards compatibility but wouldn't be run inside a complete sandbox like UAE.

The 68k code would seem to run far faster than on a real 68060.

If you wanted to use the native faster CPU you could and the 68k could call x86 libraries seamlessly.

[Karlos]

@matthey

You rather missed my point: Only a lazy programmer writes the smallest possible loop to do a job and then blames the architecture if performance sucks. The 68060 is forgiving, PPC is not, but the PPC will deliver far better perfomance when it's rules are respected.

Regarding move16, it also depends on how much you want your cache polluting. If you are copying large amounts of data it has many advantages. You should never assume that because most copies are small, they all will be; well written code ought to be prepared for any reasonable eventuality.

The alignment is never an unknown property

Check out exec.library/CopyMem(). It will copy memory of any alignment. This function is used way more than exec.library/CopyMemQuick() which does longword aligned copies. Never say never .

No, "never" is perfectly accurate. The fact that any given function may not make use of the information does not mean the information is not there to be made use of. At a machine level, you will never have a transfer of data between addresses where at least the logical alignment is not known, since you have the addresses themselves.

Failing to use that information where it is useful a bit lazy IMHO.

[persia]

Current version of Microsoft Office for Mac is intel only....

[A1260]

PPC isn't a "future".  It's a dead-end.

your correct mister i couldnt said it any better myself.......

[runequester]

From 1994, everything looks like the future

[tone007]

My AmigaOne is slow! DOWN WITH PPC!

..and don't get me started on the BPPC!

[orb85750]

I'm trying to figure out what I'm doing these days that simply could never be done on a 68060 -- seeing that it's fine for nonlinear video, etc.

[dreamcast270mhz]

To answer the OP, yes I do approve, in the form of MOS, but by now we must see that such discussions are fruitless, start flame wars and lead to ignorant comments like when Kolla called me a dumbass because of my opinion of the iMica.

Reasons why MOS, OS4 and Classic will probably never be x86.

Bye Bye to all your favorite apps native support, they all need big endian for native support of any kind

Making it x86 would involve twice the work, as its assembly code is a mess, and all our API, ABI and system calls taht have bits of ASM would all be bye bye, useless

Even if x86 was the main platform, do you know theres over 20 N/S bridge combinations currently produced?

Your average Linux or Mac geek (the market we probably would be attracting) would be pissed at:
lack of memory protection
Lack of security and privacy systems.
Unfamiliar controls, needing to learn whole new syntax (AmiDOS and derivatives)

Also, realize a 1.5 Ghz G4 beats a 3.2 GHz Pentium 4 in general performance, a PPC will give you twice (or more) performance per cycle due to its RISC and ability to execute instructions faster and more efficiently

Therefore, an x86 switch by any of those listed is HIGHLY unlikely.  Before these happen, Ronald Reagan would come back from the dead, or Kennedy.

[the_leander]

Also, realize a 1.5 Ghz G4 beats a 3.2 GHz Pentium 4 in general performance, a PPC will give you twice (or more) performance per cycle due to its RISC and ability to execute instructions faster and more efficiently

Tell me, what colour is the sky on the planet upon which you spend most of your time?

A 3.2Ghz P4 is in a whole other league of performance.

Inb4claimsofbias

[KThunder]

To answer the OP, yes I do approve, in the form of MOS, but by now we must see that such discussions are fruitless, start flame wars and lead to ignorant comments like when Kolla called me a dumbass because of my opinion of the iMica.

Reasons why MOS, OS4 and Classic will probably never be x86.

Bye Bye to all your favorite apps native support, they all need big endian for native support of any kind

Making it x86 would involve twice the work, as its assembly code is a mess, and all our API, ABI and system calls taht have bits of ASM would all be bye bye, useless

Even if x86 was the main platform, do you know theres over 20 N/S bridge combinations currently produced?

Your average Linux or Mac geek (the market we probably would be attracting) would be pissed at:
lack of memory protection
Lack of security and privacy systems.
Unfamiliar controls, needing to learn whole new syntax (AmiDOS and derivatives)

Also, realize a 1.5 Ghz G4 beats a 3.2 GHz Pentium 4 in general performance, a PPC will give you twice (or more) performance per cycle due to its RISC and ability to execute instructions faster and more efficiently

Therefore, an x86 switch by any of those listed is HIGHLY unlikely.  Before these happen, Ronald Reagan would come back from the dead, or Kennedy.

Have you ever heard of Aros?!?!

BTW dreamcast270mhz did you know that nothing on the dreamcast runs at 270mhz? the sh-4 cpu runs at 200mhz.

[dammy]

Tell me, what colour is the sky on the planet upon which you spend most of your time?

A 3.2Ghz P4 is in a whole other league of performance.

Inb4claimsofbias

So where does the dual core PA6T fall in that chart?

[the_leander]

So where does the dual core PA6T fall in that chart?

I remember when the X1000 was first demoed and all the Amigans.net and AW regulars came here in droves to big it up that Karlos put up a link somewhere showing that the PA6T wasn't a huge amount quicker per clock than the G5. It's single biggest selling point was it's low power usage compared to the G5.

Either way, it'd be nomm'ed up by anything remotely recent.

[Karlos]

I remember when the X1000 was first demoed and all the Amigans.net and AW regulars came here in droves to big it up that Karlos put up a link somewhere showing that the PA6T wasn't a huge amount quicker per clock than the G5. It's single biggest selling point was it's low power usage compared to the G5.

Either way, it'd be nomm'ed up by anything remotely recent.

Floating point performance of the PA6T was significantly higher than the G5 as I recall, though. Also remember that the performance was for one core. Of course, until OS4 / MOS get some sort of support for more than one core, that's a moot point.