Thread: 68k details
View Single Post
Old 13 November 2018, 19:13   #766
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
Quote:
Originally Posted by meynaf View Post
A lot of 100% position-independent exists (don't say relocatable, it's wrong word for this !).
Why not relocatable? Sorry I can't catch the difference. 68k has too many addressing modes to support the code relocation. It makes loader easier and smaller but it is not much important generally. MMU can provide the code relocation for free - no need to waste the instruction space by additional instructions for this.

Quote:
Originally Posted by roondar View Post
Yes it is: you ignored the rather positive 68000 article frankb posted (as I suggested to him you would) and only looked at the article that was negative.
Sorry it is not easy to find a text without its clear markers - https://archive.org/details/byte-mag...85-09/page/n41 - it is the proper link to the interview with Rod Coleman. That man really liked 68k because he thought that it was more theoretically correct. He said that 68000 has more promising architecture but he missed a simple idea that 80286 may be upgraded when the proper time comes. He missed practical advantages of 80286.

Sorry I had to add more clarification to my point. For example, for me 68000 is a bit clumsy. It is because my first x86 experience began with 80286 which is 3 years older and have a lot of very rapid instructions. Indeed I couldn't use this word if I had compared 8088 and 68000.

Quote:
Originally Posted by meynaf View Post
Always ready to shoot, hmm ?
I am always ready to present you one or even two shots of the best vodka. I feel myself as your debtor because of your numeros interesting and helpful remarks.

Quote:
Originally Posted by roondar View Post
Even the (admittedly very rare) Amiga's equipped with a 68040 did a lot better than just a few hundred sold (see http://www.amigahistory.plus.com/sales.html - the A4000/40 is listed as selling 3800 units in Germany alone).

I'm not saying that there were 68040's on every street corner, but there clearly were many more made than a few hundred. Motorola would never have bothered with a 68060 if the 68040 was that much of a failure.
I am not sure but I won't be surprised if we find out that almost all A4000/40 were sold in Germany. There was no any real mass produced 68040 based computer and there were a lot of cheap 80486 based models.

Was there any computer based on 68060? As I know it was only available as an upgrade.

Quote:
Originally Posted by roondar View Post
In any case, your original reply to me said the 486@25MHz was faster than the 68040 ("80486@25MHz gives slightly more"). And that is false even in the best case scenario. It's this false bit of info I've been trying to counter.
I can say sorry again. I was rather inattentive. And I also gave some justification to you. I consider those data as rather approximation. So there is no much difference between 20 and 21.

Quote:
Originally Posted by roondar View Post
The higher clock speeds of the 486 wasn't what we were debating however, we were discussing performance differences between the more 'affordable models' of the 486/68040 and the ARM2 in 1991. And secondarily, the performance difference between these chips at the same clock speed
My initial point was about the 90 and 91 and I have to admit that it was wrong about 1991. However Archimedes had surprisingly affordable prices considering the power of its competitors.

Quote:
Originally Posted by roondar View Post
What I am disputing is that hand written, optimised ARM2 code is significantly better compared to the compilers available for it at the time VS hand written, optimised 386/68030 code compared to the compilers available for them at the time.
You have a fact about the line drawing algorithm implementation. It is common to consider that ARM code density is significantly worse than of x86 and it is common to consider x86-32 code as the best here. However we have 80 bytes of ARM code for this algorithm and 82 for x86. IMHO compilers still make rather very poor codes for ARM - read the article - http://benno.id.au/blog/2009/01/01/s...onserving_code - it is about handmade reducing of a code produced by GCC from 100 bytes to 10! I can't imagine such a thing for x86.

Quote:
Originally Posted by roondar View Post
I'm 100% certain that comparing a single emulator is not a good way to figure this out (if only given the vastly different performance figures for different emulators emulating the same system on the same CPU* and the differences in screen memory layout). I have no doubt the performance difference here was big though - I am certainly not claiming the Archimedes CPU isn't faster.

To try and get to the bottom, I tried to get a better performance comparison. However, it's not so easy to find performance comparisons (that are better than comparing one emulator) between the A500 and ARM2. I have found some comparisons between the A500 and Amiga's running a 33Mhz 68030 though. This might be somewhat relevant as we did an earlier comparison between that and a 12MHz ARM2. I freely admit this is not the best comparison and will accept a better one if you/I can find one, but here goes:

An A2000 using a 68030@33MHz is about 10x the speed of a basic A500**. The 68030@33MHz is about 1.8x the speed of an 8MHz ARM2 according to the list we've been using. This would translate to the Archimedes being about 5.6x the speed of an A500. Which seems to be about right when looking at 3D games.

Again, this is not a great comparison and I'll gladly accept better ways to measure the difference, but it's still better than looking at a single application

*) As an example, I've had multiple C64 emulators on my expanded A1200 (I'm excluding A64 here as it has very poor compatibility). These really varied in how fast they were - one of the Amiga C64 emulators was completely unusable for me (sub 5FPS), the other worked fairly well (closer to 25FPS).

**) According to http://amiga.resource.cx/perf/aibbde.html, check the "Combo (030/33, 882/33, OCS, 3.0 in RAM)" vs the A500.
Emulators are very complex programs and therefore can give very good impression of the performance of hardware. I used text modes and Norton utilities for benchmarking. It is sad that there is no Archimedes emulator for Linix. Indeed we should take into accout the quality of emulation but I don't remember much difference except the very slow work with Amiga-500.

I don't insist that Archimedes is always 10 times faster but IMHO for proper optimised programs it can be faster about this number. I repeat my counts with the standard line drawing algorithm show that ARM can be 50% faster than 80486 at the same frequency. Amiga-500 has only slow RAM and Archimedes RAM access is 2 or even more times faster. So theoretically 68000 can only be 4-5 times slower but with Amiga it is about 10.

Thank for an interesting Amiga benchmark cite. I am a bit surprised that for some tests A1200 only 40% faster than A500. IMHO 68020 should be much faster. So it sounds as a common problem of Motorola products - their theoretical specifications are much better than practical.

Quote:
Originally Posted by roondar View Post
More seriously, this is kind of the point - you can't simply say the Archimedes is a lot faster than the A500 by looking at the CPU alone. If 2D graphics get involved the difference can completely vanish.

It will certainly win vs the A500 for business/serious software or 3D graphics, but it won't usually win the '2D war' and to me that shows that CPU power alone isn't everything and thus doesn't tell the whole story.
Indeed Amiga can show very good results with some types of graphics but I was almost shocking when 8 MHz Archimedes showed animated plane flight in a window and a Basic code for this program in another window! IMHO it was impossible to write such things in interpreted Basic, I use my Amiga experience for this estimation.

Quote:
Originally Posted by meynaf View Post
I thought it was quite self-explanatory. You need to create general-purpose functions when they're not here at first place.
Any example?
litwr is offline  
 
Page generated in 0.04367 seconds with 11 queries