68k details

[litwr]

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

     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.

[meynaf]

Originally Posted by litwr

@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

Originally Posted by litwr

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.

Originally Posted by litwr

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 :

 lea one+1(pc),a1   ; dc.b 1 somewhere
 abcd -(a1),-(a0)
 bcc .exit

[litwr]

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

Originally Posted by roondar

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.

Originally Posted by meynaf

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

[litwr]

Originally Posted by meynaf

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.

To do something like that you could simply write :

 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.

[meynaf]

Originally Posted by litwr

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.

Originally Posted by litwr

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.

Originally Posted by litwr

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

Originally Posted by litwr

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.

Originally Posted by litwr

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.

Originally Posted by litwr

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.

Originally Posted by litwr

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.

[roondar]

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

Originally Posted by litwr

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

Originally Posted by litwr

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.

Originally Posted by litwr

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

[litwr]

Originally Posted by meynaf

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

Originally Posted by roondar

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.

[meynaf]

Originally Posted by litwr

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

Originally Posted by litwr

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

First define what exactly you want to achieve.

[meynaf]

Originally Posted by roondar

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

[litwr]

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

[meynaf]

Originally Posted by litwr

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.

Originally Posted by litwr

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.

Originally Posted by litwr

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 ?

[Megol]

Originally Posted by litwr

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.

[roondar]

Originally Posted by litwr

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.

Originally Posted by litwr

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.

[grond]

Originally Posted by litwr

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.

[roondar]

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.

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

[litwr]

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

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.

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

Originally Posted by meynaf

Define what you see as "long BCD number". How many bits ?

Let's take 5 bytes.

Originally Posted by roondar

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

Originally Posted by roondar

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

[Galahad/FLT]

Originally Posted by litwr

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

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.

[roondar]

Originally Posted by litwr

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.

[litwr]

Originally Posted by Galahad/FLT

code makes no sense whatsoever!

Thank you very much. It was a strange typo, it should be

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

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.

          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,"$"

Originally Posted by roondar

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.

[StingRay]

Originally Posted by litwr

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

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!