68k details

[Kalms]

Originally Posted by litwr

I can only repeat that you can't make relocatable an instruction with two indices, for example,

MOV table(A0,D1),D2

The idea of 100% relocatable code for 68k or PDP-11 is a kind of chimeric one. You can do it on the purpose but generally it is bigger and slower. Thus above 99.9999% of 68k programs do not consist of 100% relocatable code. But 8086 gives you an opportunity to use 100% relocatable code just limiting us with its size: we have to use less than 64 KB for codes, 64 KB for data, 64 KB for a bit slower extra data and 64KB for stack. With 80386 you can expand 64 KB up to 4 GB and get two additional segments for extra data but this is not supported by DOS directly. However 80386 can give 100% relocatability with built-in MMU too. So COM-format is the demonstration of x86 ISA superiority. It should be absolutely clear now.

You are correct in that 68000 does not support table[offset1+offset2] in a PC-relative manner. 8088 does support that operation out of the box.

There is one particular situation where I have found that to be limiting in practice, and that is when I wanted to do a lookup into a global array, and fetch one single element from there. This kind of lookup:

int otherTaskPriority = TaskPriorities[otherTask]

This is only doable in a single instruction in 68000 if TaskPriorities is embedded within the current code segment, within +/- 128 bytes away, and it is a read operation. If it is further away, or placed somewhere within a data segment, or it's a write operation, then the typical 68k implementation would be 2 instructions, like this:

lea TaskPriorities_offset(a5),a0
move.w (a0,d0.w),d1   ; d0 contains scaled index into table

... whereas that would have been handled by a single 8088 MOV operation.


For any arrays that are dynamically allocated, 68000 and 8088 would use the same code for performing a single access to the array: 1) fetch the base pointer into a register, 2) perform an indexed read. In step 2 there, both 8088 and 68000 offer optional offsets. This is useful if accessing an element within a struct. 68000 has 8-byte signed offset; 8088 has 16-bit signed offset. This means 68000 would need an extra instruction if accessing member-of-struct for structs that are >128 bytes in size. I rarely come across this as being a problem.


If I'm doing more than one access to the same table, I find that there is often some form of pattern in the accesses. Because of this, for 68000 code it is normally beneficial to begin the chunk of code by loading the base of the table into an address register, and do multiple indexed accesses based of that address register. It is rare that the address is made up of two independently moving indexes, where both change between every access. Therefore, even if there was a (16-bit offset + index1 + index2) addressing mode for 68000, I would very rarely use it in code that does multiple accesses to the same table.


I find that a much bigger problem is that for 8088, the indices are limited to so few registers. It's [<16-bit offset> + <bx or bp> + <si or di>]. You need to be very careful about what goes into which registers and not try to walk many different data streams at the same time. It's not so bad if one is working strictly with statically allocated data structures, but as soon as code begins to manipulate dynamically allocated data structures, 8088 code can only "manage" two dynamically allocated data structures in parallel until the code will need to do register shuffling. For example, si = data_structure_1, di = data_structure_2. If there is a need to do indexed accesses to a third data structure, the code will begin shuffling base pointers in and out of si/di.


I find that the benefit provided by the 8088's 16-bit offset + 2 index registers addressing is much smaller than the drawback of having fewer registers than 68000 overall and much narrower choice in which registers can be used during addressing. It gets doubly complicated for programs that need to do dynamic memory allocation.

Overall, my take is that both the 8088 ISA and the 68000 ISA work well for programs of a small enough size and complexity. Is the typical program a 5-10kB executable where all memory is statically allocated up-front? Great, the 8088's instruction set is very well adapted to this. Does your program revolve around dynamic memory allocation, and it is not sufficient to pre-allocate the memory by creating large static tables? Then the 68000 instruction / IA32 set works better. Does your program need to address more than 64kB of data? Then the 68000 / IA32 instruction set works better.

I like the 68000 ISA because it provides a gradual transition from small programs to large ones - well, to programs that deal with a few GBs of memory. The 8088 ISA works well for programs that dealt with up to 64kB of data, and beyond that the ISA becomes increasingly painful to use. The IA32 ISA works well for larger programs - but supporting both 8088 and IA32 programming models at the same time makes an operating system a lot more complicated than it has to be. Overall I find that the 68000 ISA compares favorably to the 8088 ISA, and equally to the IA32 ISA.

[litwr]

Originally Posted by meynaf

But you cannot say C is nice while in the same time saying C++ is ugly : the syntax is exactly the same !

I agree with plasmab that C++ is superb but for a lazy mind it is easier to say it is ugly and do nothing instead of big studying. Let's look at a piece of my recent C++ real-time coding

if (this->config.wsReSubscribe && this->connReSubscribeFreeTsQueue.size() //resubscribe
               && ((tsQueueIt = [&]{
                   auto it = this->connReSubscribeFreeTsQueue.begin();
                   for (; it != this->connReSubscribeFreeTsQueue.end(); ++it){
                        if (this->connReadyById.find(it->second) == this->connReadyById.end())
                             continue;
                        if (it->first > base::microtime()) return this->connReSubscribeFreeTsQueue.end();
                        if (gotNoTimeout.find(it->second) != gotNoTimeout.end()) return it;
                   }
                   return it;}()) != this->connReSubscribeFreeTsQueue.end())) {

            int connId = tsQueueIt->second;
            this->connReSubscribeFreeTsQueue.erase(tsQueueIt);

Could you imagine such text in C? It is a completely new level. C++ is really hard, things like boost require years to become familiar. Life is hard too.

Originally Posted by meynaf

Did you know 68k can do the same, and without the shortcomings ? ...

68k requires special relocatable code for this. It looks like you have become tired of the discussion, you miss your arguments, don't provide proofs, etc. However it is eventually close to its end. I have got some new information about 68k and it is a pleasure. Indeed 68k is a bit clumsy, not so independent and strong as x86 or ARM but it was anyway one of the best with its unique specific beauty. It sounds like 68k code density can be the best in many cases - I thought it is much worse and I was wrong with it.

This discussion inspires me to write a piece of coding for my old iron Amiga-friend. I hope to find some spare time for it. Thanks.

Originally Posted by Kalms

You are correct in that 68000 does not support table[offset1+offset2] in a PC-relative manner. 8088 does support that operation out of the box.

Thank you very much again for your so descriptive comments. Indeed 68k is at least 50% better than 8088. It has its advantages, x86 has its own. My point about relocatable code is clear enough, it is only subset of not relocatable. You can't use some 68k addressing with it. You have to replace some instructions with slower and sometime larger equivalents. 8088 on the contary can use all its capabilities with any code limited in size of 64 KB (+192 KB for data) and get free relocatability for it.

Indeed 68000 is better for large program than 8086. But such programs were rather rare for the 80s and 80386 provided the way for convenient coding without segmentation.

[roondar]

Originally Posted by litwr

Thank you for sharing you opinion but it is not true.

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. Really, your bias is super obvious and pretending otherwise isn't going to fool anyone.

Sorry I really knows little about 68040. I know only that it was not used so widely as 80486, it had lower frequencies, problem with FP, ... I can add that it was used surprizingly rarely and was eventually replaced by PowerPC. So it showed some very serious shortcomings that prevented its success. Maybe it was also too costly.

If you know very little about something, don't make claims about it. The 68040 was used in a number of rather popular computers (a whole bunch of Macs, some Amiga's and even some Atari's).

In the list 68040@25MHz shows about 17.5 MIPS on average, 80486@25MHz gives slightly more but the difference is rather insignificant.

In the list, the 486@25MHz shows between 13 and 15 MIPS. There is not a single entry higher. Because almost all results list it as 15MIPS, this means it scores ever so slightly below 15MIPS on average. In the same list, the 68040@25Mhz shows between 17.5 and 21 MIPS, with about as many entries for 17.5 as 20 MIPS, so it averages around 18.75 MIPS. In this list the 68040 is clearly faster than the 486 - by about 25%.

And you wonder why I feel you're overly biased - claiming the 68040 is slower than the 486 based on a list that clearly shows the 68040 to be faster instead

I have only claimed that ARM@25MHz can be faster that 80486@25MHz.

Which is, according to the list you yourself provided to show how fast the ARM is, false. Continuing to claim it's true merely makes you look silly.

Indeed, the official benchmark shows that 80386@33MHz is faster that ARM@12MHz. However they sometimes used Acorn's Basic against C-compilers at x86!

The benchmarks as shown in the list you provided were not C vs BASIC, so that is completely irrelevant. The 386@33MHz is faster than the ARM@12MHz.

My experience with ARM let me say that ARM allows to write very compact and fast codes which are much better than codes generated by compilers of the 80s or even 90s.

But somehow all actual proof points to the opposite being true. In reality, ARM code compiles very well, the architecture is widely known to be 'C friendly' - you even show this earlier in the thread and at that point claim the compiler friendliness of the ARM to be an advantage.

Why do you call line drawing code untested? It is fully tested for x86, 68k and ARM. I have made very accurate cycle counting, anybody may check it. The code is rather short it will take only less than 10-15 minutes. I said "on average" because the codes have conditional instructions which timings depend on condition. I took 50-50 in those cases.

The important part of my reply here was "And what exactly does one tiny algorithm prove? (answer: nothing, really! It might be an outlier and considering other benchmarks disagree with these results, it is actually likely that it is an outlier)".

In other words, I don't really care about one tiny example were the ARM may win. It loses (as in is slower) overall and that is the only relevant bit of information.

IMHO the UK computer market was stormed by NA companies. Commodore sold 2-3 times more Amigas in the UK than in the gigantic NA market. Olivetti provided poor management and refused to use their trade net to sell Archimedes. And there was IBM PC factor too. So Acorn did rather very well and produced very good computers in those circumstances.

None of what I said was about sales figures. The above is completely irrelevant to what you and I are discussing.

I met an Archimedes with 8MHz ARM-2 in 1991, I was very impressed by its performance. It was more 10 times faster than my Amiga 500. Indeed sound and graphics of A500 was approximately at the same level.

The Arcimedes @8MHz is not 10x faster than the A500. Period.

It might, might get close to that (as in, it might reach a 8x advantage) on pure 32bit code (which is extremely rare on the A500), but it certainly isn't for code that uses a high number of 16 bit operations (which is true for the majority of code that targets an A500). Likewise, the Archimedes will start losing it's advantage over the A500 quite fast once complicated 2D graphics operations such as blitting or scrolling become required.

You seriously overestimate the Archimedes here (what a surprise ).

[Kalms]

Originally Posted by litwr

Thank you very much again for your so descriptive comments. Indeed 68k is at least 50% better than 8088. It has its advantages, x86 has its own. My point about relocatable code is clear enough, it is only subset of not relocatable. You can't use some 68k addressing with it. You have to replace some instructions with slower and sometime larger equivalents. 8088 on the contary can use all its capabilities with any code limited in size of 64 KB (+192 KB for data) and get free relocatability for it.

Yes - however, you get the full convenience in 8088 up to only 64kB to data. As you go above 64kB (not all data fits into a single 64kB data segment) it gradually gets more and more complicated. Which segment will you place a particular data structure in? Should this group of of data structures be in the saem segment? Do I want to copy things using the string operations between data structures in different data segments? between data structures in the same segment?

Originally Posted by litwr

Indeed 68000 is better for large program than 8086. But such programs were rather rare for 80s and 80386 provided the way for convinient coding without segmentation.

"such programs were rare for 80s"? Probably yes in the early-to-mid 80s. Toward the very end of the 80s, and in the 1990s, I disagree.

The 68000 provided a platform which enabled hardware creators to create OSes with significant more flexibility than the 8088-based OSes. It was only by the arrival of Windows 95 that there was a common OS that would support running multiple applications and also support a single application using all the available memory in the machine. For someone living in Sweden, using and developing on PCs during 1990-1995 was a jumbled mess of niche OSes (OS/2 & Linux) and weird DOS extensions (DOS/4GW, PMODE, code-it-yourself) until Windows 95 finally arrived with a widely-available and consistent platform just like Amiga OS had provided. Now, why did it take so long? I doubt it was because it 'wasn't needed'. I think part of the reason for the long delay for common 32-bit application support on PC was because the 8088 programming model did not offer a clean gradual upgrade path to the IA32 model. Windows 3.x did the 286-protected-mode thing to support running multiple applications, and getting 32-bit support in Windows 95 required a huge overhaul of the OS and the application programming models.

My estimation here is that the 8088 programming model served the actual computing needs from its release in 1978-or-so up until 1990.

The 68000 programming model, on the other hand, acting like a 32-bit processor and with a broader register set, served the actual computing needs from 1980-or-so up until 2000. The first two big features missing from the original 68000 chip were floating-point computation and virtualized addressing - but introducing hardware support for these in later 68k chips did not require significant changes to the programming model itself. Around the year 2000 people would have been needing SIMD instructions. Around the year 2005 people would have been needing 64-bit address spaces. That shift to 64-bit addressing would have made the most sense by shifting the entire processor architecture to 64 bits, and that 32bit->64bit shift for the 68000 architecture would have been similar in nature and scope to the IA32->x86-64 shift.

I think it is impressive for the 68000 architecture to have been relevant for the actual computing needs for 20+ years. I am a bit saddened that the business side of things made x86-based architectures win in the end.

[idrougge]

Originally Posted by litwr

C is very beautiful - it is beauty inspired almost all modern PL creators. What do you like? Fortran or Cobol?

Name one modern programming language inspired by C.

[Megol]

Originally Posted by idrougge

Name one modern programming language inspired by C.

Without a definition of "modern" the question becomes impossible to answer.
However there are a lot of languages that are inspired by C that can be considered modern with some examples being Swift (all types of it), Rust, Java, Javascript/EMCAscript(*spits*) and even Nim.

[meynaf]

Originally Posted by litwr

I agree with plasmab that C++ is superb but for a lazy mind it is easier to say it is ugly and do nothing instead of big studying. Let's look at a piece of my recent C++ real-time coding

Why do you write "this->" ?
In a C++ class you can access your class members directly.

Originally Posted by litwr

Could you imagine such text in C? It is a completely new level. C++ is really hard, things like boost require years to become familiar. Life is hard too.

Oh yes alas I can imagine that in C just too well. Lots and lots of function pointers instead of functions that are class members, leading to hard to follow calls.

But C++ maybe isn't the real problem, it might be the object-oriented paradigm ?
C++ has great features. For example function templates :

template<class t> inline void swap(t& a, t& b) {
	t ttmp = a;
	a = b, b = ttmp;
}

Try to do the same in C : absolutely impossible. You have to write one version per data type or specify said data type in a macro. Yuck.

But ok, this kind of construct is more to compensate for language primitives that should be there in any decent high-level language but are just missing

Originally Posted by litwr

68k requires special relocatable code for this.

No, you just need to have address registers point to whatever memory address you see fit, or use pc-relative modes where available.

Originally Posted by litwr

It looks like you have become tired of the discussion, you miss your arguments, don't provide proofs, etc.

Seems this applies to you.

Originally Posted by litwr

However it is eventually close to its end. I have got some new information about 68k and it is a pleasure.

Tired of the discussion, as said above

Originally Posted by litwr

Indeed 68k is a bit clumsy, not so independent and strong as x86 or ARM but it was anyway one of the best with its unique specific beauty. It sounds like 68k code density can be the best in many cases - I thought it is much worse and I was wrong with it.

It's a bit clumsy, especially 68000 compared to 68020+, but still far better than x86 and ARM !
x86 is too complex, arm is too spartan.
Proving it is very easy. Just consider the time it takes to write some code that's big enough. I can do a working program doing basic stuff in a matter of minutes in amiga asm ; i don't think you can do the same with x86 (which is the reason why you don't accept coding challenges involving code >100 insns).

That said, 68k's code density isn't exactly the best that can be obtained out of this kind of ISA. I re-encoded it (with a few additions of mine) and got 15% average gain.

Originally Posted by litwr

This discussion inspires me to write a piece of coding for my old iron Amiga-friend. I hope to find some spare time for it. Thanks.

You're welcome.

Originally Posted by litwr

Thank you very much again for your so descriptive comments. Indeed 68k is at least 50% better than 8088. It has its advantages, x86 has its own.

The one and only advantage x86 has is good todays implementations, really. Intel fabs are just awesome.

Originally Posted by litwr

My point about relocatable code is clear enough, it is only subset of not relocatable. You can't use some 68k addressing with it. You have to replace some instructions with slower and sometime larger equivalents. 8088 on the contary can use all its capabilities with any code limited in size of 64 KB (+192 KB for data) and get free relocatability for it.

Your point is clear but it is wrong. Even in the case of the 3-add if we consider 68020+ code - which I always do. Consider this :

 move.l (anyplace,pc,d0.l),d1

Yeah, label "anyplace" can really be anywhere and you'll get 16 or 32 bit offset depending on how far it is, but we're not limited to 64k.

Originally Posted by litwr

Indeed 68000 is better for large program than 8086. But such programs were rather rare for the 80s and 80386 provided the way for convenient coding without segmentation.

Sorry, but we've proven here that it remains better even for small enough programs. And while 80386 is somewhat equivalent to 68000 featurewise, it doesn't beat 68030.

[Don_Adan]

Originally Posted by litwr

I've just finished my emotional article about processors - https://litwr.livejournal.com/3096.html



I can only repeat that you can't make relocatable an instruction with two indices, for example,

MOV table(A0,D1),D2

Seems you dont have enough knowledge in 68k coding. One more instruction is necessary lea or move.l. Or PC relative version (Table must be in 126 bytes range) can be used. Or for 68020+ this is not problem. But you remembered me my 4 channels mixing routine, very fast for 68000, very short, all 68k registers was used, 9 address registers and 8 address registers, it will funny (or interesting) to check how big can be x86 or ARM version. Unfortunelly i cant extract this routine from my source on my stupid Android tablet.

[litwr]

Originally Posted by roondar

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. Really, your bias is super obvious and pretending otherwise isn't going to fool anyone.

You haven't provided a link. I didn't seek the Byte's article I just read it because it was about CPU history which is related closely to my article content. And again, I am completely disagree with you opinion about my bias.

Originally Posted by roondar

If you know very little about something, don't make claims about it. The 68040 was used in a number of rather popular computers (a whole bunch of Macs, some Amiga's and even some Atari's).

Those computers were made in a very small numbers, only hundreds... And you have missed the key phrase eventually replaced.

Originally Posted by roondar

In the list, the 486@25MHz shows between 13 and 15 MIPS. There is not a single entry higher. Because almost all results list it as 15MIPS, this means it scores ever so slightly below 15MIPS on average. In the same list, the 68040@25Mhz shows between 17.5 and 21 MIPS, with about as many entries for 17.5 as 20 MIPS, so it averages around 18.75 MIPS. In this list the 68040 is clearly faster than the 486 - by about 25%.

Sorry for being not 100% accurate but all those numbers are a mere approximation only. Indeed they show that 68040 is a bit faster but there are some controversy. For example, a line for "PRO 486/50L" gives us 20 claimed MIPs at 25 MHz. It is a bit less than 21 but it is only 5% less. More googling gives data that 68040 was generally faster than 80486 at the same frequency for about the 25% percent but 80486 were produced at 50, 66, 100, 120 while 68040 stuck at 40.

Originally Posted by roondar

But somehow all actual proof points to the opposite being true. In reality, ARM code compiles very well, the architecture is widely known to be 'C friendly' - you even show this earlier in the thread and at that point claim the compiler friendliness of the ARM to be an advantage.

The important part of my reply here was "And what exactly does one tiny algorithm prove? (answer: nothing, really! It might be an outlier and considering other benchmarks disagree with these results, it is actually likely that it is an outlier)".

In other words, I don't really care about one tiny example were the ARM may win. It loses (as in is slower) overall and that is the only relevant bit of information.

There is a big difference between manual assembly and compiling technology. The compiler optimization requires enormous resources. So we have very good optimizers for x86 today. Arm still has more poor compilers. I don't try to break your completely petrified point but I only hope I can give you some food for a bit of doubt.

Originally Posted by roondar

None of what I said was about sales figures. The above is completely irrelevant to what you and I are discussing.

There is a quite common point that Intel got a success because of IBM PC sales figure. I pointed that 68000 had them much better than ARM but ARM is more mass produced and used now than x86.

Originally Posted by roondar

The Arcimedes @8MHz is not 10x faster than the A500. Period.

It might, might get close to that (as in, it might reach a 8x advantage) on pure 32bit code (which is extremely rare on the A500), but it certainly isn't for code that uses a high number of 16 bit operations (which is true for the majority of code that targets an A500). Likewise, the Archimedes will start losing it's advantage over the A500 quite fast once complicated 2D graphics operations such as blitting or scrolling become required.

I used IBM PC emulator with my Amiga 500 at 1989 and 1990. I needed some DOS software for work and study. I could get only 10-15% of IBM PC performance. Archimedes showed more than 100% - I don't remember the exact number. This gives the mentioned 10x but maybe it is 9x or 11x.

Indeed for some kinds of graphics Amiga 500 can show quite good results.

Originally Posted by Kalms

Yes - however, you get the full convenience in 8088 up to only 64kB to data. As you go above 64kB (not all data fits into a single 64kB data segment) it gradually gets more and more complicated. Which segment will you place a particular data structure in? Should this group of of data structures be in the saem segment? Do I want to copy things using the string operations between data structures in different data segments? between data structures in the same segment?

Yes, I can repeat this, to work with large arrays is not a strong point of 8086. It is several times slower than with small arrays fitted 64 KB limit. But its quite plain, no any graduality. Indeed we have also 1 MB limit. So 8086 can't work normally with array more than 1 MB in size. 8086 quite easy to use with a code with a size less than the 1 MB. All other mentioned problems are rather contrived for programming in the 80s. You need a section for variables and small arrays and section for big data. Indeed 68k allows to use it even easier but it is rather insignificant.

BTW a rather biased for 68040 article http://www.skepticfiles.org/cowtext/...1/486vs040.htm contains an interesting phrase "The 80486 has some edge, since it allows the user to implement segmentation if needed and avail oneself to its advantages."

Originally Posted by Kalms

The 68000 provided a platform which enabled hardware creators to create OSes with significant more flexibility than the 8088-based OSes. It was only by the arrival of Windows 95 that there was a common OS that would support running multiple applications and also support a single application using all the available memory in the machine. For someone living in Sweden, using and developing on PCs during 1990-1995 was a jumbled mess of niche OSes (OS/2 & Linux) and weird DOS extensions (DOS/4GW, PMODE, code-it-yourself) until Windows 95 finally arrived with a widely-available and consistent platform just like Amiga OS had provided. Now, why did it take so long? I doubt it was because it 'wasn't needed'. I think part of the reason for the long delay for common 32-bit application support on PC was because the 8088 programming model did not offer a clean gradual upgrade path to the IA32 model. Windows 3.x did the 286-protected-mode thing to support running multiple applications, and getting 32-bit support in Windows 95 required a huge overhaul of the OS and the application programming models.

Free BSD and Linux became available at the early 90s. BTW I am a Linux user since 1997 and using Microsoft Windows rather occasionally. IMHO DOS extenders were quite good and eliminates all problems with x86 programming for large code and data. The unreal mode for 32-bit Intel processors gives you possibility to directly use DOS in real mode with 4 GB segments. The code is very easy I made and used it.

My estimation here is that the 8088 programming model served the actual computing needs from its release in 1978-or-so up until 1990.

I completely agree with you for this point.

Originally Posted by Kalms

The 68000 programming model, on the other hand, acting like a 32-bit processor and with a broader register set, served the actual computing needs from 1980-or-so up until 2000. The first two big features missing from the original 68000 chip were floating-point computation and virtualized addressing - but introducing hardware support for these in later 68k chips did not require significant changes to the programming model itself. Around the year 2000 people would have been needing SIMD instructions. Around the year 2005 people would have been needing 64-bit address spaces. That shift to 64-bit addressing would have made the most sense by shifting the entire processor architecture to 64 bits, and that 32bit->64bit shift for the 68000 architecture would have been similar in nature and scope to the IA32->x86-64 shift.

Maybe generally but in practice 68k were too slow and difficult to upgrade to keep their niche. They were replaced.

Originally Posted by Kalms

I think it is impressive for the 68000 architecture to have been relevant for the actual computing needs for 20+ years. I am a bit saddened that the business side of things made x86-based architectures win in the end.

IMHO (sorry I have to repeat) Intel made the best things for their time. For example, a 16-bit system was too expensive for a mass computer designed in 1980. But Moto introduced 68008 only in 1982! 68000 is better than 8088 but 68008 has performance almost the same or even worse than 8088! Intel made 8087 in 1980 but Moto "waited" with its math co-pro until 1984! 68030 which can only be slightly better than 80386 was released in 1987. Moto's processors were more expensive...

I could buy a 25MHz 80386-based system in 1992. For the approximately the same money I could get only 68020 @14-16Mhz. In 1993 I could buy a 80486-based at 80Mhz system and there was nothing comparable 68k-based.

[litwr]

Originally Posted by meynaf

Why do you write "this->" ?
In a C++ class you can access your class members directly.

Need a C++ lesson? When you work with large bundle of large classes with complex relations you will feel better if you can distiguish class objects and locals/parameters.

Originally Posted by meynaf

Oh yes alas I can imagine that in C just too well. Lots and lots of function pointers instead of functions that are class members, leading to hard to follow calls.

That small piece of code uses oveloaded operators and functional semantics - no way for C.

Originally Posted by meynaf

C++ has great features. For example function templates :

template<class t> inline void swap(t& a, t& b) {
	t ttmp = a;
	a = b, b = ttmp;
}

Try to do the same in C : absolutely impossible. You have to write one version per data type or specify said data type in a macro. Yuck.

But ok, this kind of construct is more to compensate for language primitives that should be there in any decent high-level language but are just missing

I agree C++ is good for template programming. I like to use just recursion with them, for example,

template<int N> struct Fib {
   enum {R = Fib<N - 1>::R + Fib<N - 2>::R};
};
template<> struct Fib<1> {
   enum {R = 1};
};
template<> struct Fib<0> {
   enum {R = 0};
};

It gives you the 46th Fibonacci number by a call to Fib<46>::R millions times faster than the next plain code

long fib(int n) {
   return n < 1 ? 0 : n < 2 ? 1 : fib(n - 1) + fib(n - 2);
}

BTW don't try to run the latter code with Amigas, it will be almost forever. Indeed we can use constexpr and the optimizer with C++ too. However recursive variadic templates are rather tough for me.

[meynaf]

Originally Posted by litwr

Need a C++ lesson? When you work with large bundle of classes with complex relations you will feel better if you can distiguish class objects and locals/parameters.

Always ready to shoot, hmm ? I don't need any C++ lesson but you might need one.
Of course you have to distinguish class members from local vars, especially if your classes are really a mess but it's not done this way for anyone who knows how to code.
Rather, prefix the names, like this : "m_something" is the class member, "something" is the local variable. This is quite common programming convention.

[litwr]

Originally Posted by meynaf

Rather, prefix the names, like this : "m_something" is the class member, "something" is the local variable. This is quite common programming convention.

Thank you but different companies like different styles. I'm not a manager.

Sorry I forgot to ask you what do you mean in detail with your phrase "But ok, this kind of construct is more to compensate for language primitives that should be there in any decent high-level language but are just missing"?

[roondar]

Originally Posted by litwr

You haven't provided a link. I didn't seek the Byte's article I just read it because it was about CPU history which is related closely to my article content. And again, I am completely disagree with you opinion about my bias.

I didn't provide a link because the article frankb referred to is found at the same link you gave: the Byte Issue you quoted an article from.

As an example of why I feel you might be more biased than you think or want to admit: the Byte article you actually did link to had a part where the author admitted this was just his opinion and not necessarily all fact. The same article also had a really rather positive part about the 68020. Both of these things were clearly relevant to the discussion and yet, you didn't mention either of them.

At any rate, this discussion about bias is getting us nowhere - all I'm essentially trying to point out is that you seem more keen on accepting stuff that makes the 68k look worse and seem rather reluctant to accept stuff that makes the 68k look better. Regardless of the reasons for why this is happening.

Those computers were made in a very small numbers, only hundreds... And you have missed the key phrase eventually replaced.

The 68040 Macs were not made in mere hundreds. They sold a lot better than that. Heck, they nearly had a hundred 68040 based models .

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.

Sorry for being not 100% accurate but all those numbers are a mere approximation only. Indeed they show that 68040 is a bit faster but there are some controversy. For example, a line for "PRO 486/50L" gives us 20 claimed MIPs at 25 MHz. It is a bit less than 21 but it is only 5% less.

The only line in that list for PRO 486/50L is this one:

PRO 486/50L         1      80486      50     40            SV  1991 $11.2K

This runs at 50MHz and if rated down to 25MHz would indeed be rated at 20MIPS. Since it doesn't actually run at 25MHz, I did not include it in my comparison as you can't always just take a higher MHz part and simply rate it up or down.

However, it doesn't really matter because we were comparing average speeds from that list. Almost all of the 486's in the list clocked in 15 MIPS, a few did below and apparently you concluded one that would do 20 if downrated. It averages out at about 15 MIPS as a result, even if we include the single 20 MIPS outlier. For the 68040@25MHz, it was split about 50/50 between 17.5 and 20MIPS, with one result giving 21. Which averages to about 18.75 MIPS.

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.

More googling gives data that 68040 was generally faster than 80486 at the same frequency for about the 25% percent but 80486 were produced at 50, 66, 100, 120 while 68040 stuck at 40.

Oh for sure, the 486 was available at much higher clock speeds (though the 66/100/120 did run the bus at a lower relative speed than the 25 and 50MHz parts and thus are every so slightly slower than at first might appear). The high speed 486's were much faster than the 68040@40MHz. No doubt about that. Claiming otherwise would be foolish.

On a side note, there are some interesting details about why the 486DX/2 is the way it is (half bus speed), but I don't feel it's required to go into them here - this thread is quite big enough already!

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

There is a big difference between manual assembly and compiling technology. The compiler optimization requires enormous resources. So we have very good optimizers for x86 today. Arm still has more poor compilers. I don't try to break your completely petrified point but I only hope I can give you some food for a bit of doubt.

Compilers do indeed create code that is (or at least can be) less optimal than manual written assembly. I am certainly not disputing that.

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.

I already felt this way, but feel this more so given your earlier point about how easy ARM2 code is to convert to C (and hence vice versa).

There is a quite common point that Intel got a success because of IBM PC sales figure. I pointed that 68000 had them much better than ARM but ARM is more mass produced and used now than x86.

Which is interesting, for sure. But our discussion was purely one of performance and thus I don't see this to be very relevant.

I used IBM PC emulator with my Amiga 500 at 1989 and 1990. I needed some DOS software for work and study. I could get only 10-15% of IBM PC performance. Archimedes showed more than 100% - I don't remember the exact number. This gives the mentioned 10x but maybe it is 9x or 11x.

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.

Indeed for some kinds of graphics Amiga 500 can show quite good results.

So much so that some of these things are still not fully replicable on even 12MHz Archimedes machines as of today

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.

[idrougge]

Originally Posted by litwr

Sorry I really knows little about 68040. I know only that it was not used so widely as 80486, it had lower frequencies, problem with FP, ... I can add that it was used surprizingly rarely and was eventually replaced by PowerPC. So it showed some very serious shortcomings that prevented its success. Maybe it was also too costly. In the list 68040@25MHz shows about 17.5 MIPS on average, 80486@25MHz gives slightly more but the difference is rather insignificant.

How many architectures used the 80486, pray tell? The 68040 was used by a lot of Macs, by Amigas, by jet fighters, by Hewlett-Packard, by NeXT, in various network equipment, in Atari and QL clones…

[Megol]

Originally Posted by idrougge

How many architectures used the 80486, pray tell? The 68040 was used by a lot of Macs, by Amigas, by jet fighters, by Hewlett-Packard, by NeXT, in various network equipment, in Atari and QL clones…

Define architectures. The 80486 was manufactured until 2008 IIRC and used in many embedded systems. But I would be surprised if most of those didn't use modified PC designs given that it works and have a lot of compatible chips.
There have been at least two designs with the 486: the PC and one Unix workstation design that wasn't PC compatible.

[Bruce Abbott]

Originally Posted by Megol

Define architectures. The 80486 was manufactured until 2008 IIRC and used in many embedded systems. But I would be surprised if most of those didn't use modified PC designs given that it works and have a lot of compatible chips.

I think it would be fair to define all PC compatibles as a single architecture, even embedded systems since their reason for using a 486 was probably to be PC compatible.

There have been at least two designs with the 486: the PC and one Unix workstation design that wasn't PC compatible.

Which Unix workstation was that?

[meynaf]

Originally Posted by litwr

Sorry I forgot to ask you what do you mean in detail with your phrase "But ok, this kind of construct is more to compensate for language primitives that should be there in any decent high-level language but are just missing"?

I thought it was quite self-explanatory. You need to create general-purpose functions when they're not here at first place.

[Megol]

Originally Posted by Bruce Abbott

I think it would be fair to define all PC compatibles as a single architecture, even embedded systems since their reason for using a 486 was probably to be PC compatible.

Many of them sure but the 486 had a nice price/performance with multiple sources. Embedded is strange sometimes, there are still COSMAC 1802 processors in use today.

Which Unix workstation was that?

Don't remember sadly. Searched before posting but didn't find it, probably have to look through old computer magazines. Could have been something similar to the Intel "supercomputer" https://en.wikipedia.org/wiki/Intel_iPSC but am not sure.

It may be either an NCR Voyager or a Sequent Symmetry 2000, not sure. Both of those used nonstandard designs (as SMP wasn't part of the PC at the time) however as I remember it the bus architecture wasn't compatible either. Will search some more.

[idrougge]

Originally Posted by Megol

Define architectures. The 80486 was manufactured until 2008 IIRC and used in many embedded systems.

Yes, I come to think of an old print server I had. Mind you, that print server was manufactured by Intel.

[touko]

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.

You're right, the amiga, and mainly the 500 was designed to have the maximum performances at the lowest cost .
The question is, what's the A500 could do with a chip ram twice as fast than the OCS one(more or less the same that the archimedes has) ??
With this kind of RAM,all the system can also run at twice the speed . Somebody know how much this would cost compared to an archimedes ??
And what's the performances we could be reach ??