English Amiga Board


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

 
 
Thread Tools
Old 08 December 2018, 11:55   #901
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
@meynaf Your point about MOVE from SR looks like a very weak position because it looks like that you try to protect a beauty of a theory. But they say Beauty is in the eyes of the beholder. I can't find anything good in a theory that Moto was bought. It shows only the weakness of Moto which often relied on the blind copying of things. You can't provide any example why reading the SR can be wrong for anything. BTW I can show you a code for which I wanted to read CCR. I had to add one to a long BCD number.
Code:
     moveq #1,d1
     move.b -(a0),d0
     abcd d1,d0
     move.b d0,(a0)
     bcc .exit   ;we can't check X :(

     moveq #0,d1
     move.b -(a0),d0
     abcd d1,d0
     move.b d0,(a0)
     bcc .exit

    ...
BCC doesn't work after MOVE. I have figured out another code which works but it looks a bit tricky.

@roondar I checked the Byte magazines for the end of 1989. They have sale offers for 8088 based PC. They were rather low end for the office computers that time but if we take into account the number of such PCs which were actually used that time we will get the impression that those computers were still popular in 1989.
litwr is offline  
Old 08 December 2018, 12:11   #902
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
Quote:
Originally Posted by litwr View Post
@meynaf Your point about MOVE from SR looks like a very weak position because it looks like that you try to protect a beauty of a theory. But they say Beauty is in the eyes of the beholder. I can't find anything good in a theory that Moto was bought. It shows only the weakness of Moto which often relied on the blind copying of things.
Nope - it's not theory. It's real life. You just didn't understand it.
https://en.wikipedia.org/wiki/Popek_...n_requirements


Quote:
Originally Posted by litwr View Post
You can't provide any example why reading the SR can be wrong for anything.
I have provided one. The fact you didn't understand it doesn't invalidate it.


Quote:
Originally Posted by litwr View Post
BTW I can show you a code for which I wanted to read CCR. I had to add one to a long BCD number.

BCC doesn't work after MOVE. I have figured out another code which works but it looks a bit tricky.
To do something like that you could simply write :
Code:
 lea one+1(pc),a1   ; dc.b 1 somewhere
 abcd -(a1),-(a0)
 bcc .exit
meynaf is offline  
Old 08 December 2018, 12:55   #903
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
The article at https://en.wikipedia.org/wiki/Motorola_68040 has words While it delivered over four times the per-clock performance of the 68020 and 68030. It is well known that 80486 was about 2.5 faster than 80386. It gives us interesting data to analyze. if 68030 can be about 33% faster than 68020 that gives us that 80386 was a bit (only by several percents) faster than 68030 in its fastest mode...

IMHO 68000 was the best Moto's CPU. It had several minor annoying quirks but it had real advantages over 8086. However it did not have a proper support. It missed co-pro and an 8-bit variant until 1982, systems based on it were much more expensive until the mid 80s. 68020 was rather a step in the wrong DEC direction. Its ISA became too heavy to support in the incoming world of fast processors. Some elements of the PDP-11 design are exactly copied to 68k architecture even in detail. For example, the only PDP-11 instruction that lacks full orthogonality is XOR...

It is interesting to have a fantasy about an imaginary world where some beaten technology gets superiority - http://www.desertpenguin.org/blog/wh...z180-z280.html - Zilog might have ruled the world! It will be interesting to read a similar article about Motorola. IBM used two 68000 in its famous XT/370 and AT/370 cards...

Quote:
Originally Posted by roondar View Post
You thinking it's odd doesn't make it so. I can keep repeating this it seems: actual, real world results don't agree with your opinion. In the real world almost no one used the FPU for these and as such, removing it from the FPU didn't change much.
You have mentioned the famous FDIV Pentium bug. It was discovered by a user who needed FPU for his calculations. When a man needs FPU it is logical for him to get all options. Try to imagine a user who made his own software using FPU with 68030+68882 when he discovered that his programs works much slower with the newest and very expensive 68040? It could be only a complete disappointment. Indeed that man would have preferred to find something better and this was a demand for PowerPC. It is interesting why 68050 was abandoned - they could fix 68040 problems with it.

Quote:
Originally Posted by meynaf View Post
Learn how to count. This is 4 instructions, not 5
Thank you for a math lesson. Your skills in math are very impressive and you have persuaded me that in the most cases 68k has better code density as 86k. However that was given for a very high price, by the intensive use of the address registers...

Last edited by litwr; 08 December 2018 at 13:13.
litwr is offline  
Old 08 December 2018, 12:59   #904
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
Quote:
Originally Posted by meynaf View Post
Nope - it's not theory. It's real life. You just didn't understand it.
https://en.wikipedia.org/wiki/Popek_...n_requirements
I have provided one. The fact you didn't understand it doesn't invalidate it.
x86 uses virtualization quite fine and allows to read MSW. Just blindly repeat some text doesn't mean that you understand it. It was a popular theory that Earth can't be round. Almost all ppl were convinced.

Quote:
To do something like that you could simply write :
Code:
 lea one+1(pc),a1   ; dc.b 1 somewhere
 abcd -(a1),-(a0)
 bcc .exit
I have to keep a lot of zeros too for such an approach.

EDIT. Just read the Wikipedia's article more carefully - VMMs for non-virtualizable ISAs (in the Popek and Goldberg's sense) have routinely been built. MOVE from SR gives only a tiny shortcoming for a very contrived case which can be easily fixed by price of several more CPU's cycles but Moto created a real problem with it.

Last edited by litwr; 08 December 2018 at 13:15.
litwr is offline  
Old 08 December 2018, 13:15   #905
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
Quote:
Originally Posted by litwr View Post
The article at https://en.wikipedia.org/wiki/Motorola_68040 has words While it delivered over four times the per-clock performance of the 68020 and 68030. It is well known that 80486 was about 2.5 faster than 80386. It gives us interesting data to analyze. if 68030 can be about 33% faster than 68020 that gives us that 80386 was a bit (only by several percents) faster than 68030 in its fastest mode...
Perhaps you will have to get your maths right again. Where did you getch that 80386 is a bit faster than 68030 ? It's not. And nothing in the numbers you wrote above can tell otherwise.


Quote:
Originally Posted by litwr View Post
Thank you for a math lesson. Your skills in math are very impressive and you have persuaded me that in the most cases 68k has better code density as 86k. However that was given for a very high price, by the intensive use of the address registers...
No the price isn't "very high". Definitely not.
And anyone who has ever used ADDA.W auto sign-extend feature could even say it's actually better this way.


Quote:
Originally Posted by litwr View Post
x86 uses virtualization quite fine and allows to read MSW.
Tell that to people who had to implement it, e.g. the Sandboxie authors... Virtualization on x86 is a real PITA to do !
(And, as they say in their readme, not perfect and some programs can easily detect it.)


Quote:
Originally Posted by litwr View Post
Just blindly repeat some text doesn't mean that you understand it.
Start by understanding it yourself, for now it's obviously not the case.


Quote:
Originally Posted by litwr View Post
It was popular theory that Earth can't be round. Almost all ppl were convinced.
And ? This does not in any manner imply you're right in anything.


Quote:
Originally Posted by litwr View Post
I have to keep a lot of zeros too for such an approach.
No. Just keep the LEA in the loop.
Seems you really need to learn how to code, my friend

EDIT.
Quote:
Originally Posted by litwr View Post
EDIT. Just read the Wikipedia's article more carefully - VMMs for non-virtualizable ISAs (in the Popek and Goldberg's sense) have routinely been built. MOVE from SR gives only a tiny shortcoming for a very contrived case which can be easily fixed by price of several more CPU's cycles but Moto created a real problem with it.
Read it yourself.
That same paragraph continues with "The virtualization of such architectures requires"...
And a lot of dirty methods follow.
meynaf is offline  
Old 08 December 2018, 13:21   #906
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,364
Edit: it would really be much more convenient if you replied to my post just once instead of spreading it over three or four different posts

Quote:
Originally Posted by litwr View Post
@roondar I checked the Byte magazines for the end of 1989. They have sale offers for 8088 based PC. They were rather low end for the office computers that time but if we take into account the number of such PCs which were actually used that time we will get the impression that those computers were still popular in 1989.
Popularity says nothing about performance though.

Your claim about 8088 based PC's: "8088 based systems were quite good as a middle class of computer to the end of 80s". This claim is wrong, these systems were clearly low end stuff that basically only still sold because they were cheap and because offices at that time only needed well, really crappy computers. They were not popular because they were 'good' in 1989 and certainly not because they were 'a middle class of computer'.

Why not? Well, in PC land a middle class of computer in 1989 would've been either a fast 286 or a slow 386. Probably with VGA at that time. Which is miles better than the 8088 PC you're comparing it to.

Quote:
Originally Posted by litwr View Post
You have mentioned the famous FDIV Pentium bug. It was discovered by a user who needed FPU for his calculations. When a man needs FPU it is logical for him to get all options. Try to imagine a user who made his own software using FPU with 68030+68882 when he discovered that his programs works much slower with the newest and very expensive 68040? It could be only a complete disappointment. Indeed that man would have preferred to find something better and this was a demand for PowerPC. It is interesting why 68050 was abandoned - they could fix 68040 problems with it.
Your hypothetical man would be a very rare one indeed as the real world disagrees with your stories. In the real world, almost no FPU using program was impacted by the 68040 FPU redesign. I've pointed this out several times (complete with source for the claim and benchmark results that show the 68040 FPU was very fast indeed) and asked you to produce some evidence against it if you disagree. Oh and as a bonus: the 68040 FPU changes were known from when it was released and not a bug that cost its parent company several hundred million dollars.

Instead, you wrote a silly fantasy story that tries to appeal to emotion. It's 100% clear you have no evidence for your position.

Quote:
Originally Posted by litwr View Post
@roondar
8-bit data bus at 65816 slows down this CPU very much. My point was that a 65816 variant with 16-bit data bus @4MHz should be faster than 68000 @8MHz.
That is not what you claimed originally, now is it. Anyway...

I'm not going to argue about your point there because you're describing a non-existent CPU and I don't feel like speculating about what could've been if only important design factors of our favourite CPU's were rather different (such as say doubling the speed by changing the bus). IMHO that just doesn't make much sense.

Not that fantasizing about what could've been is wrong by default (it can be fun I suppose), it IMHO just doesn't have a place in threads about real world performance etc.

Last edited by roondar; 08 December 2018 at 14:08. Reason: Edit: added more replies to points scattered in different posts
roondar is offline  
Old 08 December 2018, 14:40   #907
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
Quote:
Originally Posted by meynaf View Post
Perhaps you will have to get your maths right again. Where did you getch that 80386 is a bit faster than 68030 ? It's not. And nothing in the numbers you wrote above can tell otherwise.
68040:80486 - 1.25:1
68040:68030 - 4:1
80486:80386 - 2.5:1

Let's do the calculations and we get that 80386:68030 - 1.28:1 - 80386 is 28% faster. If we assume that 68030 can be 20% faster than 68020, we will get 1:07, but as I know 68030 is usually only not more than 10% faster than 68020. I know that you know how to add 1...

It'll be interesting to look at your code for BCD addition of 1...

Quote:
Originally Posted by roondar View Post
Popularity says nothing about performance though.

Your claim about 8088 based PC's: "8088 based systems were quite good as a middle class of computer to the end of 80s". This claim is wrong, these systems were clearly low end stuff that basically only still sold because they were cheap and because offices at that time only needed well, really crappy computers. They were not popular because they were 'good' in 1989 and certainly not because they were 'a middle class of computer'.
Popularity means that the most ppl were satisfied by the performance. I can repeat 8088/86 at 10 MHz is only about 20-30% slower than PC AT @6MHz and a use of V20/v30 gives us the same performance as PC AT. Indeed PC AT @12MHz was much better but it was much more expensive, I could afford such a computer only in the beginning of 1991.
litwr is offline  
Old 08 December 2018, 14:59   #908
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
Quote:
Originally Posted by litwr View Post
68040:80486 - 1.25:1
68040:68030 - 4:1
80486:80386 - 2.5:1

Let's do the calculations and we get that 80386:68030 - 1.28:1 - 80386 is 28% faster. If we assume that 68030 can be 20% faster than 68020, we will get 1:07, but as I know 68030 is usually only not more than 10% faster than 68020. I know that you know how to add 1...
So now you have invented ratios and attempt to prove something based on them ? Where do they come from anyway.

I could write other values and it would then be totally different :
68040:80486 - 1.5:1
68040:68030 - 3:1
80486:80386 - 2.5:1

And then calculations would say :
68030:80386 - 1.25:1.

Which is closer to reality.

Anyway cpu speed comparisons like that are meaningless. I've seen code that's faster on 50Mhz 68030 than on 25Mhz 68040. It really depends on too many factors for just saying "cpu A is n% faster than cpu B".


Quote:
Originally Posted by litwr View Post
It'll be interesting to look at your code for BCD addition of 1...
First define what exactly you want to achieve.
meynaf is offline  
Old 08 December 2018, 15:28   #909
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
Quote:
Originally Posted by roondar View Post
Your hypothetical man would be a very rare one indeed as the real world disagrees with your stories. In the real world, almost no FPU using program was impacted by the 68040 FPU redesign. I've pointed this out several times (complete with source for the claim and benchmark results that show the 68040 FPU was very fast indeed) and asked you to produce some evidence against it if you disagree. Oh and as a bonus: the 68040 FPU changes were known from when it was released and not a bug that cost its parent company several hundred million dollars.
Some funny fact about this, is that even though current x86 still support old x87 instructions such as fsin, such an instruction is slow and inaccurate, and some c compilers (such as msvc) use a software implementation instead...
meynaf is offline  
Old 08 December 2018, 15:34   #910
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
Quote:
Originally Posted by meynaf View Post
Tell that to people who had to implement it, e.g. the Sandboxie authors... Virtualization on x86 is a real PITA to do !
(And, as they say in their readme, not perfect and some programs can easily detect it.)
What is a REAL problem if some program can detect virtualization? It is always possible basing, for example, on timings. I have been using virtual machines under x86-64 Linux much and have to say that it is quite stable and reliable software. I could run my Windows XP, various DOS versions, Plan 9, Free BSD, other Linuxes, Kolibri, Menuet, ... I have never had problems. I haven't ever heard about problems with the virtualization at x86. Moto was tried to be more correct that the correctness itself.

Quote:
Originally Posted by meynaf View Post
So now you have invented ratios and attempt to prove something based on them ? Where do they come from anyway.

Anyway cpu speed comparisons like that are meaningless. I've seen code that's faster on 50Mhz 68030 than on 25Mhz 68040. It really depends on too many factors for just saying "cpu A is n% faster than cpu B".

First define what exactly you want to achieve.
All my ratios were taken from respectable sources. 68040:68030 ration is taken from the Wikipedia's article about 68040. 68040:80486 ratio is taken as a result of the discussion in this thread. I hope roondar can confirm this. 80486:80386 ratio is taken from Oral history interview with John H. Crawford, who created 80386, 80486 and Pentium. However Wikipedia article about 80486 gives a ratio 2:1 but it means even a much worse number for 68030.

Indeed every CPU has some unique advantages but I took the numbers which claimed to be as a something average.

I wrote that I needed to add 1 to a long BCD number and I didn't want to keep many zeros in memory for this task.

Last edited by litwr; 08 December 2018 at 15:49.
litwr is offline  
Old 08 December 2018, 16:33   #911
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,603
Quote:
Originally Posted by litwr View Post
What is a REAL problem if some program can detect virtualization? It is always possible basing, for example, on timings. I have been using virtual machines under x86-64 Linux much and have to say that it is quite stable and reliable software. I could run my Windows XP, various DOS versions, Plan 9, Free BSD, other Linuxes, Kolibri, Menuet, ... I have never had problems. I haven't ever heard about problems with the virtualization at x86. Moto was tried to be more correct that the correctness itself.
Of course it's not the end user who has most of the problems. It's the people who write virtualization software. Did you write such software ? It not, you're not qualified to judge.

But if you just want to see the limits, run a virtualization program inside of another virtualised program, and so on. You will quickly hit it : x86 can virtualize only a fixed amount of levels because it's not full virtualization.

You may be interested in this reading :
http://www.govmlab.com/news-section-1/
https://www.anandtech.com/show/2480/3
https://en.wikipedia.org/wiki/X86_virtualization

You will see that, even if doable, it's far from being easy. The hypervisor needs to scan the executed OS to change some of its instructions !
All this workaround would not occur if proper privilege traps were implemented when designing the ISA.


Quote:
Originally Posted by litwr View Post
All my ratios were taken from respectable sources. 68040:68030 ration is taken from the Wikipedia's article about 68040. 68040:80486 ratio is taken as a result of the discussion in this thread. I hope roondar can confirm this. 80486:80386 ratio is taken from Oral history interview with John H. Crawford, who created 80386, 80486 and Pentium. However Wikipedia article about 80486 gives a ratio 2:1 but it means even a much worse number for 68030.

Indeed every CPU has some unique advantages but I took the numbers which claimed to be as a something average.
Well, so you just took numbers at the random, from various sources... Don't expect these results to be consistent.


Quote:
Originally Posted by litwr View Post
I wrote that I needed to add 1 to a long BCD number and I didn't want to keep many zeros in memory for this task.
Define what you see as "long BCD number". How many bits ?
meynaf is offline  
Old 08 December 2018, 16:47   #912
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 369
Quote:
Originally Posted by litwr View Post
x86 uses virtualization quite fine and allows to read MSW. Just blindly repeat some text doesn't mean that you understand it. It was a popular theory that Earth can't be round. Almost all ppl were convinced.
AAAARGHAA!

X86 had to introduce a new virtualization mechanism in order to be "pure" enough. Not just a mode - a super-mode that required significant changes. AMD did it their way and Intel did it in another - so x86 isn't as an architecture virtualizable at all as there is no standard way to create a virtual machine!

And the 68k? The problems were patched in the 68010 in 1982, 23 years before Intel! It required a few changes unlike the super-mode of x86.

Last edited by Megol; 08 December 2018 at 16:59.
Megol is offline  
Old 08 December 2018, 17:52   #913
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,364
Quote:
Originally Posted by litwr View Post
Popularity means that the most ppl were satisfied by the performance. I can repeat 8088/86 at 10 MHz is only about 20-30% slower than PC AT @6MHz and a use of V20/v30 gives us the same performance as PC AT. Indeed PC AT @12MHz was much better but it was much more expensive, I could afford such a computer only in the beginning of 1991.
It still doesn't matter. Your claim was not that people were satisfied with it's performance, but that it was 'middle class' performance in 1989. And that is false no matter how many times you repeat it. It was low end and seen by almost everyone as borderline obsolete.

As for pricing, I've Googled a bit and found an advert from oktober 1989 showing the price difference between a 12MHz 286 and a 10MHz 8088 being only about $300 (see attached image). IMHO, you'd have to have been pretty crazy to buy an 8088's in 1989 - you could get 4x the performance for almost the same price.

Quote:
Originally Posted by litwr View Post
All my ratios were taken from respectable sources. 68040:68030 ration is taken from the Wikipedia's article about 68040. 68040:80486 ratio is taken as a result of the discussion in this thread. I hope roondar can confirm this.
I can confirm that the 68040 was about 25% faster than the 486 in benchmarks (at the same clock speed).

However, IIRC the 68030 vs 386 claim here is wrong. We also looked at the 68030 vs 386 in this thread and IIRC the conclusion was that in benchmarks, the 68030 was ever so slightly faster than the 386 at the same clock speed (there wasn't much in it though - the difference was below 10%). However, the 68030 was available at higher clock speeds* than the 386 so the top end models of both will still have the 68030 winning by a fairly big margin.

*) The 386SX topped out at 40MHz but was slower than the DX model, the full 386DX topped out at only 33MHz. Meanwhile, the 68030 was available up to 50MHz.
Attached Thumbnails
Click image for larger version

Name:	pc_8088_vs_286_1989.PNG
Views:	35
Size:	83.1 KB
ID:	61142  

Last edited by roondar; 08 December 2018 at 18:11.
roondar is offline  
Old 08 December 2018, 21:09   #914
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 654
Quote:
Originally Posted by litwr View Post
What is a REAL problem if some program can detect virtualization?

Is that a serious question? The program can behave differently on purpose depending on whether it is running in a sandbox and thus under observation or on real hardware. One example would be some program that behaves nicely in virtualisation (and thus higher likelihood of being observed) and executes spyware or worse when running on real hardware.
grond is offline  
Old 08 December 2018, 22:59   #915
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,364
Other than what grond wrote, the real problem with software based virtualization compared to hardware based lies in the required complexity.

The Wikipedia article on x86 virtualization contains a ton of info here. I'll provide a short quote that shows my point, but if you read it you'll see there is a lot of effort needed to get virtualization working without hardware support, whereas on systems that do meet the requirements to do virtualization it's much, much easier.

Quote:
Originally Posted by x86 virtualization wiki
In the late 1990s x86 virtualization was achieved by complex software techniques, necessary to compensate for the processor's lack of virtualization support while attaining reasonable performance.
A note here is that performance is also impacted, which given proper hardware support for virtualization just isn't the case (as noted in the articale).

Link: https://en.wikipedia.org/wiki/X86_virtualization
roondar is offline  
Old 09 December 2018, 23:27   #916
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
I know IBM used to use up to 5 levels of virtualization with its mainframes even with IBM/370. Maybe with modern mainframes they can use virtualization even of level 10. However they have a big history of development of specialized OS for those mainframes. Did we have such software for 68k? I don't know about such programs. I mean systems that run a virtual machine inside a virtual machine. Thus Moto as usual did blind copying, tried to fight an artificial, pure theoretical problem, which affected nobody, and created irritating incompatibility. And I can repeat that it always possible to find a way to detect virtualization.

Sorry I can't compete with 68k experts with pi-spigot now. Maybe later. But I have recently discovered an algorithm which clearly shows that 8088 code density can be much better than 68000. It is about conversion of a 32-bit unsigned integer into a decimal string. Let's look at a 68k implementation

Code:
todec:   ;converts d5 to stringbuf, it occupies 44 bytes
          lea stringbuf(pc),a2
.l1:      move.l d5,d2
          move.l d5,d0
          clr.w d0
          swap d0
          divu #10,d0
          swap d0
          swap d2
          move.w d0,d2
          swap d2
          divu #10,d2
          move.w d2,d0
          swap d2
          or.b #'0',d2
          move.b d2,(a2)+
          move.l d0,d5
          bne .l1
          rts
And there is a x86 implementation.

Code:
todec:    ;convert dx:ax to stringbuf, it occupies 30 bytes
          mov bx,stringbuf
          mov si,10
.l1:      mov cx,ax
          mov ax,dx
          xor dx,dx
          div si
          xchg ax,cx
          div si
          or dl,'0'
          mov [bx],dl
          inc bx
          mov dx,cx
          or cx,ax
          jnz .l1
          retn
Quote:
Originally Posted by meynaf View Post
Define what you see as "long BCD number". How many bits ?
Let's take 5 bytes.

Quote:
Originally Posted by roondar View Post
It still doesn't matter. Your claim was not that people were satisfied with it's performance, but that it was 'middle class' performance in 1989. And that is false no matter how many times you repeat it. It was low end and seen by almost everyone as borderline obsolete.

As for pricing, I've Googled a bit and found an advert from oktober 1989 showing the price difference between a 12MHz 286 and a 10MHz 8088 being only about $300 (see attached image). IMHO, you'd have to have been pretty crazy to buy an 8088's in 1989 - you could get 4x the performance for almost the same price.
I wrote 8088 based systems were quite good as a middle class of computer to the end of 80s. It has not a word about performance. Though those systems were rather low middle class, they had performance about the same as Amiga 2000 or Atari ST or even a bit faster than A2000. They could run a lot of software, easily be expanded, ...

Quote:
Originally Posted by roondar View Post
I can confirm that the 68040 was about 25% faster than the 486 in benchmarks (at the same clock speed).

However, IIRC the 68030 vs 386 claim here is wrong. We also looked at the 68030 vs 386 in this thread and IIRC the conclusion was that in benchmarks, the 68030 was ever so slightly faster than the 386 at the same clock speed (there wasn't much in it though - the difference was below 10%). However, the 68030 was available at higher clock speeds* than the 386 so the top end models of both will still have the 68030 winning by a fairly big margin.

*) The 386SX topped out at 40MHz but was slower than the DX model, the full 386DX topped out at only 33MHz. Meanwhile, the 68030 was available up to 50MHz.
My opinion is close to yours but I have given a bit different data which show that there is another possibility.


EDIT. I have fixed a typo in 68k code. Thanks to Galahad/FLT

Last edited by litwr; 10 December 2018 at 04:53.
litwr is offline  
Old 09 December 2018, 23:36   #917
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,314
Quote:
Originally Posted by litwr View Post
Sorry I can't compete with 68k experts with pi-spigot now. Maybe later. But I have recently discovered an algorithm which clearly shows that 8088 code density can be much better than 68000. It is about conversion of 32-bit unsigned integer into a decimal string. Let's look at a 68k implementation

Code:
todec:   ;converts d5 to stringbuf, it occupies 44 bytes
          lea stringbuf(pc),a2
.l1:      move.w d5,d2
          move.w d5,d0
          clr.w d0
          swap d0
          divu #10,d0
          swap d0
          swap d2
          move.w d0,d2
          swap d2
          divu #10,d2
          move.w d2,d0
          swap d2
          or.b #'0',d2
          move.b d2,(a2)+
          move.l d0,d5
          bne .l1
          rts
code makes no sense whatsoever!

you're moving a word size from D5 to D0 at the start of your routine, you're then immediately doing a CLR.W D0 which will clear away what you moved from D5!!

Then you're swapping D0 which is irrelevant because its empty, then you're doing a DIVU.W #10,d0 when theres nothing there and swapping D0 back!

Never mind the rest of the routine that relies on whats in D0, your routine fails from the third instruction.
Galahad/FLT is offline  
Old 10 December 2018, 02:37   #918
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,364
Quote:
Originally Posted by litwr View Post
I wrote 8088 based systems were quite good as a middle class of computer to the end of 80s. It has not a word about performance. Though those systems were rather low middle class, hey had performance about the same as Amiga 2000 or Atari ST or even a bit faster than A2000. They could run a lot of software, easily be expanded, ...
You do realize 'middle class computer' is in part a statement about performance, don't you? Namely that it is 'middle class' or 'middle of the road' or 'midrange'. None of these is true - the 8088 was clearly low end.

As for speed, the A500/A2000 would've had a clearly faster CPU (as we discussed earlier, 68000 is about 1,3x the speed of an 8086 at the same MHz and the 8086 is about 1,3x the speed of an 8088 at the same MHz so a 7,1MHz 68000 = about a 12MHz 8088). And that's not getting into the much better system design and much, much faster graphics subsystem the A500 has.

The 8088 wasn't a good buy by the end of the 1980's. As I've shown you, 286 based PC's were extremely close in price - but 3-4x as fast. So I repeat: you'd have to been mad to buy a 'decked out' 8088 with EGA and HDD when you could get a much, much better PC for almost the same price.

Your comparison with the A2000 is actually rather strange given that it could actually be expanded into something useful for serious work. By 1989 the A2000 could have a 68030/68882 accelerator and a 386sx bridgeboard added to it, both with several megabytes of RAM. Very pricey, sure. But possible - unlike the dead-end that was the 8088 based PC, which offered zero future prospects to the buyer in 1989.
roondar is offline  
Old 10 December 2018, 04:42   #919
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 164
Quote:
Originally Posted by Galahad/FLT View Post
code makes no sense whatsoever!
Thank you very much. It was a strange typo, it should be
Code:
.l1:      move.l d5,d2
          move.l d5,d0
So I accidentally put w instead of l. Sorry. I have just fixed the text. There is also a code to check it below.
Code:
NUMBER = 500001
start    move.l #NUMBER,d5
         bsr todec
         move.l  #libname,a1         ;open the dos library
         move.l 4,a6
         jsr     OldOpenLibrary(a6)
         move.l  d0,a6
         jsr     Output(a6)          ;get stdout
         move.l  d0,d1                   ;call Write(stdout,buff,size)
         move.l  #stringbuf,d2
         moveq   #11,d3
         jsr     Write(a6)
         
         move.l a6,a1
         move.l 4,a6
         jmp  CloseLibrary(a6)
libname  dc.b "dos.library",0
stringbuf dc.b "..........",10
It prints digits in reversed order. The next code is for a check with DOSBOX.
Code:
          org 100h
NUMBER=500001
          mov ax,NUMBER and 0ffffh
          mov dx,NUMBER shr 16
          call todec
          mov ah,9
          mov dx,stringbuf
          int 21h
          int 20h
stringbuf: db "..........",13,10,"$"
Quote:
Originally Posted by roondar View Post
As for speed, the A500/A2000 would've had a clearly faster CPU (as we discussed earlier, 68000 is about 1,3x the speed of an 8086 at the same MHz and the 8086 is about 1,3x the speed of an 8088 at the same MHz so a 7,1MHz 68000 = about a 12MHz 8088). And that's not getting into the much better system design and much, much faster graphics subsystem the A500 has.

Your comparison with the A2000 is actually rather strange given that it could actually be expanded into something useful for serious work. By 1989 the A2000 could have a 68030/68882 accelerator and a 386sx bridgeboard added to it, both with several megabytes of RAM. Very pricey, sure.
It.was cheap and easy to buy NEC V20 replace 8088 with it and get 30% performance gain.
litwr is offline  
Old 10 December 2018, 06:41   #920
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,239
Quote:
Originally Posted by litwr View Post

Sorry I can't compete with 68k experts with pi-spigot now. Maybe later. But I have recently discovered an algorithm which clearly shows that 8088 code density can be much better than 68000. It is about conversion of a 32-bit unsigned integer into a decimal string. Let's look at a 68k implementation

Code:
todec:   ;converts d5 to stringbuf, it occupies 44 bytes
          lea stringbuf(pc),a2
.l1:      move.l d5,d2
          move.l d5,d0
          clr.w d0
          swap d0
          divu #10,d0
          swap d0
          swap d2
          move.w d0,d2
          swap d2
          divu #10,d2
          move.w d2,d0
          swap d2
          or.b #'0',d2
          move.b d2,(a2)+
          move.l d0,d5
          bne .l1
          rts
The 68k version can be done much shorter!
StingRay is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Any software to see technical OS details? necronom support.Other 3 02 April 2016 13:05
2-star rarity details? stet HOL suggestions and feedback 0 14 December 2015 06:24
EAB's FTP details... Basquemactee1 project.EAB File Server 2 30 October 2013 23:54
req details for sdl turrican3 request.Other 0 20 April 2008 23:06
Forum Details BippyM request.Other 0 15 May 2006 01:56

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 16:57.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.13914 seconds with 16 queries