68k details

[roondar]

Originally Posted by litwr

I can only repeat that Xlife-8 doesn't have any Chip RAM accesses during benchmarking in its screen off (calculation only) mode, so it is a pure CPU test.

This is only possible on an Amiga 1200 with 32 bit Fast RAM installed. Any program running on a stock A1200 (i.e. one with 2MB of RAM and no expansions) will always have wait states for RAM access, regardless of whether or not the display is on or off. The only effect activating the display can have is potentially adding even more wait states if the display mode requires lots of DMA (i.e. high resolution/colour count). Remember here that running a program on an unexpanded A1200 means the program is running from the slow Chip RAM by default.

---

Originally Posted by litwr

I hope you are a more polite man than meynaf and know how to say "Excuse me".

I'm not going to apologise for being correct.

You are wrong it mentions the 68010. Your sheet is only a part of a bigger document - https://cdn.hackaday.io/files/169484...ement_Unit.pdf - so your point that the 68451 was released before 1982 is rather wrong.

Edit: please note, I rewrote this part of my reply as I had misremembered what I had said. I've gone back and checked and changed my reply to accurately represent what I wrote earlier. Apologies for any confusion.

You'll find I never claimed any specific date. With regards to the document I linked, I claimed two things: that it didn't contain info on the 68010 and that this probably (but not definitively, meaning I left the door open for other evidence) meant the document was from before the release of the 68010. Both of these statements were accurate with regards to the document I found. Now, you found a more complete version of this document. And I freely admit that you finding this more complete document that I didn't manage to find does mean that it's indeed likely that the 68451 was released circa 1982/1983.

However, this doesn't change my point, nor prove me wrong. In fact, it does rather the opposite: this document by Motorola shows that my position that the 68451 was not designed for the 68010 only (your claim), but was actually designed for the 68000 and the 68010 (my claim) is quite correct. Your point about the release date of the 68451 isn't actually relevant here for what I'm trying to show.

Note that this also proves the point I was making about you not accepting facts I provide.

Look, I have nothing against you and would really love to have a more normal discussion without all these extremes and allegations. But the fact is that you seemingly won't accept anything I write, regardless of how much evidence I end up supplying (which you frankly often seem to just ignore, regardless how good or bad it is) - even if I point you to things that are literally right there in the evidence/documents you yourself provide.

You know I am an author of materials about different processors, my last one is about IBM mainframes - https://litwr.livejournal.com/3576.html BTW the 68k people often speak about such feature as relocatable code, the IBM mainframes almost ignore it - it is minor for serious tasks.

This is not at all relevant to what I was saying. My point here is that you opened this thread with a title that suggests it's about 68000 details, while in reality it's mostly you telling people all about the flaws in the 68000 you perceive to exist. You then go one step further and defend all your points to the hilt, even (and sometimes especially) the ones that are clearly not correct and/or challenged.

And you completely missed my point about the 8086. It was a mainstream trend to tell that the 68000 was much better than 8086. My analysis shows that it was generally only slightly better but still better. So you words about the worse and even more worse 68000 is your another overt lie.

Calling people liars when they are not lying isn't particularly nice . I didn't even mention the 8086 in the text you're replying to here, I was referring to what you're writing about in this thread - which is almost universally negative towards the 68K.

All your next arguments resemble me a cheap and bad trick when a man shows a side of a coin and says that the other side is the same.

That's not nice coming from someone who has misrepresented what I wrote a several times already. More so because what I write/wrote is actually mostly accurate.

Even meynaf agreed that this matter is very uneasy and controversial. No clear proofs were still provided. My blog contains also a phrase "the code density of the 68k is often better than that of the x86".

This doesn't change that your blog and this thread (now that it's merged certainly) do in fact contain several statements by you that code density is worse on the 68000/better on x86. Something which, as far as I can see, you are still defending as of now. Calling me a liar for pointing this true fact out seems more than a little unfair.

My claims are always quite clear that the 68000 was faster than the 8086 but the 80286 was faster than the 68000 and even faster than the 68020 for 8/16-bit work. All other claims are controversial we still can't find the truth. IMHO the discussion shows that the 80386 matches the 68030, the 80486 - the 68040, and the 68060 - the Pentium. So you again wrote a lie.

No, I've accurately summarized your position when looking at your blog and your forum posts (it's not one or the other) about 68K speed vs X86 speed. I did not lie, you constantly are trying to prove the x86 processors (of all grades) were in fact faster (like two years ago with your endless benchmark claims).

It is only your way of thinking. I haven't written than the x86 instructions are generally better. I have written about numerous quirks of the 68k instructions. I have also written about many advantages of the 68k. So you again guilty of false evidence.

Even if what you say here is true (which in my opinion after reading your blog post and your many forum posts about this issue isn't the case), at worst I misread your blog post. Which is very different from telling a lie.

Understand that my reactions here are mostly based on that. I do not agree with most of the things you say, but I try to stay civil regardless. I only become 'short' and less friendly when you start doing things like claiming I'm lying or misrepresenting what I'm saying by leaving important elements of what I write out of your replies.

But it is a really fantastic. It was implemented in 1982 and modern processors still have its timings! The 68020 and 68030 have 2 times slower division. So I have had rights to write such words.

Thank you for proving my point. The 286 division instruction isn't 'fantastic' if you take all of the information into account. (and modern processors do division in a single cycle, so no... 286 timings were definitely not kept).

Case in point: it's not usually actually 2x faster. The fact of the matter is that the 286 was generally sold at much lower clock rates than the 68020 (and certainly much lower ones than the 68030). Most 286's were sold between 8 and 12MHz, while the 68020 was usually sold with a minimum speed of 16MHz. The 68030's most common speeds were 25, 33 and 50MHz. This means that in the real world, the division on 286 were almost never 2x the speed of those of the 68020/68030 and in fact often ended up being slower than that of the 68020/68030.

No. Maybe using my materials, it is likely to make a conclusion that the x86 has less quirks than the 68k. Yes, it is my point and I backed up this my opinion with many details. However those quirks are minor drawbacks maybe they are not drawbacks at all but just oddities which can irritate some people. So you are guilty of this lie too.

Admitting I have a point here (which you just did) means admitting I'm not lying.

No, you are again trying to pervert my ideas. My point is in an idea that the 8086 segments was quite a right thing for its time. I always write that the 68k flat space is better but in the early 80s it was not important. So there is yet another your lie.

Point me to were you actually say the 68K flat address space is better without adding one or more red-herrings or caveats to downplay this advantage and I'll agree with you. But all I see is statements in which you at best start by agreeing it's better but end by saying it was either irrelevant at the time (which isn't true) or that segmentation was somehow a good alternative (which also isn't true). So, again - no lie on my part.

Relative code is a good feature but it was minor for serious systems. Indeed it can help a bit sometimes but it is not a necessity. You can write code relocatable inside a segment for the x86 too but who needs such an oddity? It is difficult for me to compare PC relative code and x86 segmentation, you are rather exaggerating the meaning of this topic. And again, it is your another lie - I haven't written that one thing is better or worse.

You know, I've reread the thread and I admit I got this wrong. You quoted Byte magazine which made an argument that relative code was not used very frequently (which is not actually true, the vast majority of 68K code is written in a relative way - direct writes to addresses without going through an address register are rather rare) and I took that to be your opinion. However, you do make many claims about segmentation being a good thing, so I'm not all wrong here. Calling this a "lie" is clearly stretching things.

MIPS is not perfect and even far from perfect but it provides us with some information.

Except between different architectures, where it doesn't really.

[Thomas Richter]

Originally Posted by litwr

I have added information about one more oddity of the 68000 "Moreover, from the contrived Big Endian byte order, addition and subtraction operations with 32-bit numbers are performed with an additional slowdown". Indeed this was later fixed by 32-bit data bus of the 68020.

I wonder why you believe that big-endia order is "contrieved". Otherwise, we would have the year 1202, and not 2021. It is one of two possible conventions, and that's all about it. Big-endian means that the magnitude of bits is monotonically declining for multi-byte numbers, and I believe that is a nice property. Unless you come from IBM and denote the most-significant bit as bit #0.


I find it bewildering that you worry about such conventions.

Originally Posted by litwr

Thank you very much. This perfectly explains the situation. Xlife was 32-bit since its first version and it has still been using 8x8 tiles.

Again, if you want to add 8x8 tiles, you are welcome.

Originally Posted by litwr

I have mentioned an additional stack for parameters... Besides that it is really not easy to use more than 256 bytes on stack for an 8-bit program if it doesn't use recursion.

That depends on whether you push parameters on the stack or not, or keep variables on the stack or not. The 6502 is not good at such things - it's better with "everything global, everything static". Recursion is not such a new thing, but almost all higher programming languages (probably with the exception of FORTRAN) support it, so some kind of (emulated) stack is required.

Originally Posted by litwr

But 8-bit systems never have enough stack space for recursion. If a recursive program needs more than 256 bytes it can usually ask for more than 1024 bytes sometime or even more than 10240.

Except that a 1024 byte stack on a Z80 would have been easy, but it's hard on the 6502 - everything must be done manually.

Originally Posted by litwr

I can't agree that "'move from sr' should have been privileged from day 1". The 68000 had to have a separate privileged instruction to read system flags and a normal instruction to read arithmetic flags.

System flags are of no business to user space programs.

Originally Posted by litwr

However people said "compared to the 8086/8088, it [the 68000] required a massive software effort to get it to do anything" (Byte 9/85).

I don't know how people come to this claim. Probably with the background from 8080, things look "bewilderingly different", but that's not a processor thing.

Originally Posted by litwr

IMHO far/near calls are almost ideal way to do subroutine calls on a 16-bit system.

It's not the *calls* that made the problem. The pointers are. If you wanted to access more than 64K on the contrieved (and I really mean it) addressing model of the intels, you had to keep both the segment and segment offset in a combined "far" pointer.

Originally Posted by litwr

People like to say about segments but they usualy forget that segments are not a problem. They just want a 32-bit registers but we had a time in the 1978-1983 when even 16-bit systems were too expensive. Moto made its 68000 for mini-computers.

So, why did then intel threw this junk overboard? It was a really bad design decision that was much in the way of further improvement. Mot made one good move here: Through the old junk overboard, start with a clean house design.

Originally Posted by litwr

It is your point but you can't still prove it. There is a way. Try to make the 'generate' routine in Xlife-8 for the Amiga less than for the IBM PC without degrading its speed.

Look, I don't really mind too much. All I can offer is the source if someone wants to try, but that's a completely useless pissing context. In the end, it depends on the setup. VE's 32x32 blocks works fine as far as I'm concerned, and it works better if the setup is sparser, but that's just a configuration matter.

Originally Posted by litwr

It seems you know little about the 68k. So maybe you are not a 68k expert as I might think of you? Thomas Gunter told us: "Well the main thing that we did is we added complexity to the machine, especially in transitions. As we went up the chain a little bit to 68010, 68020, we created a monster in terms of all the addressing modes that we had.

The 68010 didn't have any new addressing modes. The 68020 had. Actually, pointless ones, yes. I do not quite know why they did that - they scaled this junk down with the coldfire machines. In fact, the only extension that remained was the scaling of the index, which is actually quite useful. Double indirection I had really rarely any use of, and it creates a couple of headaches MMU-wise. Though does movem, I wouldn't have added this instruction either.

Originally Posted by litwr

I wrote about the x86 and ARM quirks too. However Moto liked quirks much more than Intel or Acorn.

I'm sorry, but what about the all-incompatible, legacy-junk real-modes and protected modes, and "system-service interrupt" one cannot block on the intel? The A20 gate, which is just an all-around system nightmare? Intel always had the approach of "make it backwards compatible", which is not a bad principle, no. It just piled junk on top of junk... Motorola didn't do that, for good or for bad.

Originally Posted by litwr

You know that the Moto's 680x has also a bunch of quirks. Those quirks made Moto's products more expensive (quirks require transistors!), slow and difficult to expand. Indeed most of them were not issues of primary importance.

Did I say A20 gate?

Originally Posted by litwr

Indeed the 68020 was a big step ahead and it had a lot of very good features. But Moto added also some quirks like the third stack, more decimal instructions, RTM, ... Moto couldn't persuade its customers to continue the use of the 68k, maybe because the 68020 was not fast enough for this. Indeed it was also because of a poor management.

I wouldn't be so sure... this was mostly a market decision with IBMs architecture getting more market share. As always, it's not the best system that wins the market, but "who is first to the market". Look at VHS vs. Betamax vs. Video2000. The worst system made the win, until the next "quantum leap" happened and tape-based video recording systems became all obsolete.


Probably something similar happens now, probably arm is taking over. I wouldn't miss the A20 gate and the "too many modes" of the intel CPUs.

Originally Posted by litwr

It is only your very specific personal problem. And you again ignore my point that Intel just think that ppl would have been happy in protected mode in the 80s like it is for 25 years now.

You cannot start a system without the real mode, and without A20 gate, even today.

Originally Posted by litwr

Errors break software but we have a case when Moto actually broke some software in order to follow a pure theory. They had 3 years to find a better way.

You still don't understand the problem. Too bad. The "theory" was not at all to break the system, but to provide an Os-trap to fixup such software. That was pretty much the same move they made with the 68040 FPU, which wasn't a complete FPU implementation, but rather depends on software to cover the less important side conditions and instructions. From a system design, this makes sense - do everything in software what's cheaper to do in software, and don't waste silicon if you can do it cheaper and easier by code.


So, the way how a 68010 should work is that the Os installs a "priviledge exception trap handler", and within it, check whether "move from sr" was attempted to execute, and then "fake up" the right system flags for the caller, potentially emulated system flags.


This is a different design paradigm than intel "let's carry all legacy junk around for ethernity", but one that would allow, in principle, to get away with less and cheaper silicon because not all junk needs to kept there.

Originally Posted by litwr

You go to the same loop again. My point still is, why should supervisor software read that bit at all?

Supervisor software has access to entire SR because it has to know the interrupt level, or the S bit. However, in a virtual machine, code has to made to believe that it is the supervisor, even though it is running in a sand box, and there it is the owner of the sandbox that has to provide the right emulation or the right system flags. So the system flags do not come from the CPU, but from the emulation (e.g. for emulated interrupts).

Intel learned this "sandbox principle" only years later. I wonder why that is so hard to gasp.


Things like that became important with "VirtualBox" or "VMWare", and are very important today - computing centers work with "all virtual machines" today.

Originally Posted by litwr

It sounds like your only personal fantasies. What is existing code in 1981? A lot of virtual machine software for the 68000 which didn't even have MMU or virtual memory?! Please be serious. It was a clean Moto's failure.

No, a design path. For the 68000, it was too late to fix that, but these two important fixes in the 68010 made virtual machines possible. Ok, it was too early for this idea, but I think its stunning that they had this in mind even back then when intel still messed with their segment pointers.

Originally Posted by litwr

BTW code for rare existing sandboxes had to be updated anyway because of change of status of MOVE from CR. So there was no any problem with existing code.

No, they didn't. You still don't understand. If I execute "move from sr", it is the sandbox emulation layer that provides the "emulated" version of sr. That does *not* require an update of existing code. It requires a new service in the operating system, rightfully so.

Originally Posted by litwr

IMHO IBM just wanted a good personal computer.

Errr, no. They wanted a cheap competitor to the Apple II, without creating an in-house competitor to their "real machines". That was the plan. "Fast to create, cheap, budget, for the masses".

Originally Posted by litwr

The IBM PC was the best PC in 1981. They made a computer for masses not for classes.

It was the only "PC", thus "naturally". It tried to attack Apple II, that was the price-point.

[Thomas Richter]

Originally Posted by litwr

I am absolutely sure that there is no C-compiler which check Carry or Overflow after an assignment.

Then you don't know much. The following code is not so uncommon, and allows a clear carry-over to 68K code:

if ((a = b) >= 0) {...}

would compile to a single move, followed by a "blt.s" instruction, and thus requires clearing overflow.


Thus, again, there is an orthogonality principle here that would be violated if carry or overflow flag would not be cleared. Consider that "move" would only set "Z" and "N" flags. Then you could use some branch instructions safely after a "move", namely "beq/bne/bmi/bpl", but others, you could not, like "bgt, bge, blt, ble". This would violate "orthogonality".

Originally Posted by litwr

I don't understand how the presence of extra BSR.W or BRA.W instructions relates to orthogonality?

Same thing again. If there is a "branch on condition X", then there should be a "branch always" as well, and since we have a "jmp always" and "jsr always", we also need "bsr always".

Originally Posted by litwr

And moreover this orthogonality feature was rather DEC ads than real useful feature.

See above, simpler code generation. My interpretation of the story.

Originally Posted by litwr

IMHO there has been something weird in a fact that long integer arithmetic is still so poor supported. It was quite easy to have 64- or 128-bit integers in compilers for the x86, 68k, or even 6502, and Z80. It seems the IBM mainframes could reserved exclusive rights to use such numbers.
Anyway ADDX and SUBX can be used with bytes and words and in these cases more addressing modes can actually help.

As in, when? If you process multi-precision artithmetics, you need to iterate through a (larger) set of (lower precision) numbers, so the most useful addressing mode is ADDX register,register and ADDX -(reg),-(reg) as this is a big-endian machine and carries move towards higher magnitudes.

Originally Posted by litwr

I don't think that no more than 128 bytes per record was a common case for 32-bit programs even in the 80s.

Even more so as the indexed modes are for the cases where such structures are kept in arrays. In such cases, your struct ought better be short.

Originally Posted by litwr

Anyway I don't understand your idea about "Make the life easier for the common case for a higher programming language". Do you mean compiler users or developers?

Code generation. The 68K is a easy target for a code generator. Two types of registers, all equal, all instructions on each register of each type possible, no "special rules" like "multiply only with one register" or "shift only with another register". That's how intel worked.

Originally Posted by litwr

Users can't be affected by machine language details.

They are if the compiler creates better code.

Originally Posted by litwr

And for developers, to handle 127- and 129-byte record differently is more difficult task than do not use so small offsets at all.

You don't handle such records, not regularly. Make the common case easy.

Originally Posted by litwr

Sorry it seems that you just missed my idea. Let me repeat it. I just propose to change the way of execution of MOVE from SR. I offer just rename it to MOVE from CCR. And, indeed, we need to add a privileged instruction to read system flags. You know some instruction of the earlier 80386 were later changed.

That wouldn't work. Again, "move from sr" reads sytem flags. If it reads something else, you break the system, and you break compatibility. With the 68010 way of doing, a 68010 with a proper Os trap can execute 68000 code perfectly fine, and it can enclose it in a virtual machine, so it's necessary that the instruction remains as is, though requires (forcefully!) operating system support to learn whether it is executed in a virtual machine or not.

Originally Posted by litwr

So we can fake system flags in new MOVE to CCR, ignore them, or even keep them correct - it will change nothing if we follow documentation.

That would break compatibility, and there would be no way of the Os providing compatibility. It's a bad idea.

Originally Posted by litwr

Excuse me, the 68k since the 68010 had MOVE from CCR instruction. So IMHO you wrote rather odd things.

MOVE from CCR is something new, yes. But again, you wouldn't really use this instruction. That's nothing a compiler needs to generate. The Os needs something like that.

Originally Posted by litwr

The 80286 needs 22 cycles for DIV and the 68020 needs 44 + time for EA calculation.
The 80286 needs 14 cycles for MUL and the 68020 needs 28 + time for EA calculation.

Thank you.

Originally Posted by litwr

What does the A20-gate thing has in common with the x86 architecture?

A LOT! Did you know that the A20 gate needs to be part of the CPU nowadays, simply because to keep caches consistent? The problem with an "external" A20 gate is that the CPU cache would cache wrong data (or would loose consisteny with external RAM) with the gate switched. Actually, a couple of third-party intel-compatible CPUs had defects in such a way that A20 was not rolled correctly into the CPU cache.


Probably try to read the intel errata sheets or "spec changes", and see what piles up from this early nonsense. It is a clear case of "make a mistake once, you have to support it for a lifetime". Even an i7 or XEON of today has A20 emulated, as part of its internal architecture, and its CPU cache. THAT is a quirk. A gigantic mess.


That's a question of design philosophy, as stated before. Mot would have through out the "real mode", and A20. Intel still keeps the mess alive. Has to, as the Bios still (after so many years) has to depend on it.

Originally Posted by litwr

Nothing. It was an effect of super-popularity of MS-DOS operating system.

Since the 80286 wealthy customers used protected mode software which knew nothing about the A20-gate.

Nope. That's part of the CPU cache architecture. It's internal in the CPU nowadays. It's a big "puke!".

Originally Posted by litwr

It seems that you just protest against 16-bit architectures. Do you you know a better way to make a 16-bit processor than the way of the 8086?

No, I protest against the quirky, contrieved way how intel tried to solve the transition to wider architectures. A20, segment pointers... all rather badly engineered solutions to the problem of providing a larger address range.


I believe AMD made things considerably better with the transition to x64. Well, intel tried with a clean room approach (itanium) but they failed miserably. Too bad, nice idea, but too late.

Originally Posted by litwr

There were enough good software for x86... All good Amiga software were eventually ported to the x86... I don't know what is wrong with real or protected modes. IMHO they are quite natural things.

Clearly software was ported, I don't doubt that. But what's wrong with real and protected mode.Two types of pointers, for example? So additional work for porting. Luckely, this junk was never part of any ANSI/ISO certified language. Another quirk for a bad design decision. Memory segments.

Originally Posted by litwr

Yes, it is my main background idea! Intel made processors which just fitted its time. Intel upgraded them when proper time for this came. Moto tried to be faster than time, they did processor for some future but they were wrong about the actual future.

That's called "management". "intel" just wrapped more glue and duct-tape around its CPU, and now, after so many years, other architectures seem to become faster. Finally - away with this junk. Reminds me of Boings 737-Max. More hot-fixes to get the plane flying in faster time, using less resources for proper engineering. Engineering managed to fail...

Originally Posted by litwr

So people were asked to pay for their believes in Moto's prophecies - it was crazy. Smart people figured it out by 1982, you know Bill Joy's site "It became clear that Motorola was doing with their microprocessor line roughly the same mistakes that DEC".

That was all a market decision IBM made with the PC, and Mot missing the price point. I guess Mot underestimated the "ready to the market".


The PC is a powerful architecture, but it's full of wierd historical accidents, like multiple execution modes nobody uses today anymore, and really really absurd workarounds like A20, that still creep into today's CPU designs.


This junk has to stop, and apparently, Apple is trying to do so. We'll see, they hopefully don't make the same mistake Mot made. Their CPU needs to become ready for the masses. The arm architecture already is, in smartphones, just there not powerful enough.

[a/b]

Originally Posted by litwr

The 80286 needs 22 cycles for DIV and the 68020 needs 44 + time for EA calculation.
The 80286 needs 14 cycles for MUL and the 68020 needs 28 + time for EA calculation.

Source? I see different numbers, e.g. https://zsmith.co/intel_i.php#idiv states 25 and 21, respectively.
Also, you speak as if extra time for EA calc is super bad. With x86 you're limited to specific registers (dx:ax) and have no flexibility. Doing several mul/div in a row? Time for some data shuffling! It's an archaic approach from 8-bit era, along many other x86 'features'.

286 didn't have a barrel shifter? Shifts/rotates take a variable number of cycles (just like 68000/010). I'd say that's a big oopsie compared to 020.

[Thomas Richter]

Another attempt at an apples to oranges comparison. The 80286 has several forms of MUL, 8x8->16, and 16x16->32. The 8x8->16 takes 13 cycles for register, 16 for memory, the comparable 16x16->32 takes 21 cycles, or 24 cycles. This is from the intel 80286 manual.

Unfortunately, it does not state whether this is "worst case", "always" or "average case". The 68020 manual states 28 cycles + EA worst case, where the case depends on the number of 1 bits in one of the multipliers IIRC, so it would typically be faster.

litwr, if you provide numbers, please provide the correct numbers. What I found is from the official intel 80286 manual. Thank you.

[Thomas Richter]

Also, I find this quite interesting:

https://allaboutprocessors.blogspot....els-80286.html

I guess I can only agree with Bill Gates here. Brain-dead processor. Two modes, but can only switch to protected mode, but not back. Well, that is a "quirk".

[roondar]

Now, I can be wrong here as it was over two years ago. So, keep that in mind.
But as far as I can remember the discussion back then, the Intel cited cycle times for the x86 lineup excluded the time required to fetch/prefetch the instructions from memory (if any - depending on cache etc), while the M68K manuals included them, albeit for zero wait state memory.

If that is the case, which again I'm not 100% certain of, this would change the values cited even more.

[dreadnought]

I don't care what Bill says. I remember playing Wolfenstein on my mate's gf's dad's 286 Turbo 20Mhz and it was the future

[roondar]

Originally Posted by dreadnought

I don't care what Bill says. I remember playing Wolfenstein on my mate's gf's dad's 286 Turbo 20Mhz and it was the future

Obviously, I won't tell you that you're wrong to like playing such a nice game. These kind of memories is what this whole retro-scene is all about

However, I do want to note here that Wolfenstein wasn't a PC only game and that it ran just fine on properly equipped Motorola based computers as well (in fact, the Mac version of Wolfenstein had 4x the texture resolution of the PC version). I guess this is the point - if the 286 was such a great CPU, then the Motorola based systems would never be able to compete with that. But they actually could without issues, proving that the 286 by itself wasn't that special compared to the competition after all.

[dreadnought]

Originally Posted by roondar

I guess this is the point - if the 286 was such a great CPU, then the Motorola based systems would never be able to compete with that. But they actually could without issues, proving that the 286 by itself wasn't that special compared to the competition after all.

Obviously, I was not entirely serious (and probably meant the game more than processor itself). I know absolutely nothing about these chips' internals or how they compare. I'm sure Motorola was a worthy - if not better- competitor, if you guys say so.

History of computing/gaming is however full of "better" designs which lost to their somewhat inferior counterparts, proving that tech specs aren't always the key factor. In this case arguably for the better, because I shudder at the thought of what would come to pass if the walled garden philosophy became the status quo.

[roondar]

To be fair, the walled garden was mostly an Apple thing. Commodore, Atari and the many Unix-M68K systems were quite open.

That said, I do actually mostly agree. The Atari/Amiga/Apple were all IMHO better designs than any of the early PC's (in some ways much better even), but they all lacked one key thing: IBM's and later Microsoft's muscle in the business sphere. By 1985, PC's had a roughly 50% market share of the entire computer market already and most of that was in the business world which meant exposure to many, many ordinary consumers. Competing with that was never going to be easy. This, combined with the extremely expandable nature of PC's from day one made them easy to customize to your needs. For the competitors, this usually ended up costing more money due to the economies of scale and having less support. Of course, the flip side is that many people never actually upgraded their PC's - round my parts you would find XT's with just 640KB all the way up to 1992-1993.

[a/b]

Originally Posted by dreadnought

I don't care what Bill says. I remember playing Wolfenstein on my mate's gf's dad's 286 Turbo 20Mhz and it was the future

Yeah, obviously sarcastic. No matter, and as Roondar hinted, this has nothing to do with 286. Stick any equivalent cpu into the box and you won't notice a difference when playing Wolfenstein.
Why? Simple: chunky mode is all you need. And with planar modes on A500, you are toasted. If we are talking 286, fair is fair, so 020 and A1200, then you can do it to a certain extent. But it took the companies a while to get to that point, if they even bothered. The ceiling was too high, among other things going on with Amiga, unlike chunky mode where even a monkey can do it fast.

And btw: no, I don't want to turn this into yet another Wolf/Doom thread, there's too many already. Yeah, even C64 'can do it'. I don't care, I'm talking about good visual quality and ease of implementation.

[litwr]

Originally Posted by BippyM

Right... Firstly don't start another thread continuing from another thread. I have merged both threads. Do not create a third..

@litwr are you here just to troll amiga coders and piss them off? I've not read the first thread, sorry but 1001 very technical posts are too time consuming for my little brain, but judging by the responses in thread 2,we'll it seems you are... If that is the case then I strongly recommend you stop.

IMHO maybe it is not the best idea to combine two threads because
1) the combined thread has become so large that it is very difficult to navigate its content;
2) the first thread was stopped about 26 months ago;
3) people who are participants in both threads now have a slightly different attitude to many of the discussed topics than they did 2 years ago.

I also have a remark about the phrase "you here just to troll amiga coders and piss them off" - I am an Amiga coder too.

It has been very sad to read your phrase "I strongly recommend you stop". What is wrong for you in this discussion? It is a very technical, we are digging into little details associated with the 68k and other contemporary architectures. If I write some information which is unacceptable on this forum I am ready to leave this thread or just tell me what is unacceptable exactly. You can just write me a PM about it.
Thank you.

Originally Posted by chb

That's quite some nonsense. A 12 Mhz 68000 system could be bought in 1984 for less than $3500 from Stride Micro* (400 Series) or for less than $2500 from Pinnacle (clones of the former). That would give you 256k or 512k of RAM and a disk drive (no HDD).

Litwr, in general, please do some research before you state something as a fact. It's rather disrespectful in a discussion to just make up things and have other people check and correct them.

Thank you. I posted somewhere in this thread a link to the site of the person who created the Sage and Stride computers. It is a very interesting story which tells us that computer business is not just based on technology. This man had to leave his company in 1984. The Sage computers were quite known, we have Wiki page and other materials about them. But information about the Stride is very difficult to find. It seems that only few of them were produced and they were sold mostly in Europe. The Pinnacle was even more rare. Rod Coleman wrote that his company produced only about 10,000 units of all Sage models. So one can estimate that the Stride and later Pinnacle computers had much less number of total units made, maybe less than a thousand.
The ad you mention says that 12 MHz is only an option and it is 12 not 12.5 MHz. This ad is also dated by 1985 not 1984. So you can notice that it is easy to make an error. I agree that the price could be below $3500 for a base model with 256 KB RAM and one floppy drive. But it was rather an exotic option, I thought about a mainstream work station class computer with several megabytes of RAM and this option was above $10,000 and even $20,000. Indeed, $20,000 was a wrong number for the case. It seems that systems based on the 68000@12MHz and 80286@6MHz could have almost identical prices in 1984 though the 68000 systems were more costly.
I didn't make a mistake intentionally - I rather exaggerated too much. I just wanted to emphasize that the 80286@6MHz and even @8MHz systems were mass produced and their prices went down rapidly while the 68000@12MHz systems were rare and unusual. Indeed I made this emphasis too strong. You know Wikipedia has a lot of errors but it doesn't mean that Wikipedia writers are disrespectful for their readers. BTW I estimate my forum posts as less reliable information than information in Wikipedia but I estimate my blog entries about CPU history as more reliable than Wikipedia. Men are not perfect but we can help each other. Like you helped me to find more correct information. Thank you again.

Originally Posted by meynaf

Your two sentences here contradict each other.
If 68000 had to have separate instruction to read system flags and a normal one to read arithmetic flags, then it means it should have privileged move from sr (and move from ccr that goes with it) from day one...

I meant that MOVE from SR should not have read arithmetic flags at all.

Originally Posted by meynaf

But is it worth doing ? You wouldn't accept the result, saying it's a special case or whatever. You've already did this in the past.

How can I reject a result? If you can make the procedure smaller it will be a fact. However this shouldn't degrade the procedure speed. How could I ignore facts? I think you mean pi-spigot implementation which uses stack memory. It was accepted but as a trick only, a conventional program can't use such tricks. So this implementation shows that some strange tricks can help the 68k gets a better code density. It was a very interesting result. Many thanks to its author.
I am really interested to make Xlife-8 code better. I can repeat "any help is welcome". Thank you in advance.

Originally Posted by meynaf

Well, so it is kinda 'unfinished' and therefore not usable for cpu comparisons.

What a strange claim! Indeed any code can be optimized. Is it something new for you? So I ask you again to help me make code for the 68000 faster and get better results for this processor. It can show the 68000 and 68020 superiority. I am always glad to find an opportunity to improve programs in my project pi-spigot, Xlife-8, ... So if you believe that the 68k can show better speed just try to show it.

Originally Posted by meynaf

If you want facts : there is no 68k code which i can't enter, but i'm not able to produce valid reassembler output for even a simple x86 program, let alone a whole game. I'm not alone in that case and i know noone who can do the job on x86.

Join open source projects. You can also complain it is difficult to be a pirate in our time.

Originally Posted by meynaf

For me they look a lot like door calls of x86...

Sorry, I don't understand. What do you mean?

Originally Posted by meynaf

Not comfortable, no. We lose the ability to work directly on memory (oh sorry, the ARM of course just can't do that), and it makes carry/overflow detection more unwieldy.
It's a shortcoming, and one that's a lot bigger than having two carries.

I hardly call two carries a shortcoming, it is just an oddity which shows how strangely Moto spent its transistor budget. Maybe you are right about this ARM shortcoming, I wrote about it quite overtly in my blog entry more than two years ago - - so you again write wrong thing about my blog.

Originally Posted by meynaf

No, the ARM does not allow unaligned access to memory. Else why would ARM lovers need to check lower bits of addresses ?
But 68020 allows unaligned access to memory.

I wrote about the modern ARMs, indeed, the old good ARM can't do unaligned accesses. So I wrote rather misplaced information. Sorry.

Originally Posted by meynaf

Seems you've done a very nice strawman fallacy here.
Why would we want to do that anyway. It has no sense.

It is your clear miss again. MOV RCX,[RBX] is a quite ordinary move from memory to a register.

Originally Posted by meynaf

Which proves 68040 is clock-by-clock faster than PPC.

Just check the information I provided for you. Let read it again.
"Quadra 700 with the 68040@25MHz has 0.89 CPU performance value on Speedometer 4.02
The same computer running with the PPC@50MHz has 2.59 CPU performance value on Speedometer 4.02
So it is easy to conclude that the PPC is about 45% faster than the 68040 at the same frequency".

Originally Posted by meynaf

Read again the bold part. In 1981 IBM PC was the only PC there was so of course it was the best ! It's like winning a race where you're the only participant

What a crazy idea! There were a lot of other computers: the Apple II, Commodore 8032, Atari 800, Tandy TRS-80, TI-99/4A, CP/M computers. However, the IBM PC was the best among them.

Originally Posted by meynaf

It's pretty much impossible that cumulative result is zero.
And to answer your iffy question : to be intellectually honest, or to avoid further contributions giving the same optimisations over and over.

If you are serious why didn't you write an article about your "discoveries".

Originally Posted by meynaf

The gain is almost zero, but the loss is also almost zero.

Agreed but why did they spend transistors for this zero effects?

Originally Posted by meynaf

While this can count, it's not enough to explain the large difference.

Optimization can make code several times larger. So it can explain this difference quite perfectly.

Originally Posted by roondar

This is only possible on an Amiga 1200 with 32 bit Fast RAM installed. Any program running on a stock A1200 (i.e. one with 2MB of RAM and no expansions) will always have wait states for RAM access, regardless of whether or not the display is on or off. The only effect activating the display can have is potentially adding even more wait states if the display mode requires lots of DMA (i.e. high resolution/colour count). Remember here that running a program on an unexpanded A1200 means the program is running from the slow Chip RAM by default.

Check my data. For the ER value calculation only the A1200 with fast RAM is used when screen is off. Why do I repeat this the third time for you?

[litwr]

Originally Posted by Thomas Richter

Again, if you want to add 8x8 tiles, you are welcome.

It is an interesting challenge. Maybe in the future.
However it is sad that Amiga programs are often without sources even on Aminet. You know that a man who converted Xlife v2 to Microsoft Windows and Amiga published sources only for Microsoft Windows.

Originally Posted by Thomas Richter

System flags are of no business to user space programs.

Yes, it is my point too. MOVE from SR must have read only system flags and we should have had MOVE from CCR since the 68000.

Originally Posted by Thomas Richter

It's not the *calls* that made the problem. The pointers are. If you wanted to access more than 64K on the contrieved (and I really mean it) addressing model of the intels, you had to keep both the segment and segment offset in a combined "far" pointer.

It is a direct consequence of 16-bit architecture. You know that other 16-bit processors used similar architectural solutions. Check for example, the Z8000 or PDP-11. The 65816 doesn't use segments but it has only few addressing modes if we need access above 64 KB. The 68000 is actually a 32-bit processor with 16-bit ALU, this makes it better to handle larger memory amounts than 16-bit processors.

Originally Posted by Thomas Richter

So, why did then intel threw this junk overboard? It was a really bad design decision that was much in the way of further improvement. Mot made one good move here: Through the old junk overboard, start with a clean house design.

I can only repeat that the 8086 is a 16-bit processor and you don't know a better way to make a 16-bit processor. Actually the 8086 was in many ways the best 16-bit processor.
You can even write that Ancient Greeks could design a perfect 1024-bit processor and use it. Technologies became cheap enough for making 32-bit systems only by 1985. You ask Intel "do nothing because in the future you must do a better thing". It sounds very odd, doesn't it?

Originally Posted by Thomas Richter

Look, I don't really mind too much. All I can offer is the source if someone wants to try, but that's a completely useless pissing context. In the end, it depends on the setup. VE's 32x32 blocks works fine as far as I'm concerned, and it works better if the setup is sparser, but that's just a configuration matter.

It was rather our talk with meynaf. I ask him to help me to make Xlife-8 faster and try to prove that the 68000 code density can be better for Xlife-8 main algorithm than code density of the 8086.

Originally Posted by Thomas Richter

The 68010 didn't have any new addressing modes. The 68020 had. Actually, pointless ones, yes. I do not quite know why they did that - they scaled this junk down with the coldfire machines. In fact, the only extension that remained was the scaling of the index, which is actually quite useful. Double indirection I had really rarely any use of, and it creates a couple of headaches MMU-wise. Though does movem, I wouldn't have added this instruction either.

meynaf likes MOVEM, I also find it quite useful. Why do you think that MOVEM is rather an extra?

Originally Posted by Thomas Richter

I'm sorry, but what about the all-incompatible, legacy-junk real-modes and protected modes, and "system-service interrupt" one cannot block on the intel? The A20 gate, which is just an all-around system nightmare? Intel always had the approach of "make it backwards compatible", which is not a bad principle, no. It just piled junk on top of junk... Motorola didn't do that, for good or for bad.

I wrote system boot routines and I know that the modern way to enable the A20 line is to use port 92h. There were other ancient ways using the keyboard controller or BIOS INT call. It was an external circuitry. They had to add some support for it in the 80486 and later processor because of caching. All this thing were made for DOS only. This gate can affect only a programmer who writes a boot procedure. It is all about 2-3 lines of typical code in this procedure. Its importance for software is zero! I hardly call this even a quirk, it is rather a way to keep compatibility with OS which was very popular until 1995. BTW do you know that

Intel no longer supports the A20 gate, starting with Haswell. Page 271 of the Intel System Programmers Manual Vol. 3A from June 2013 states: "The functionality of A20M# is used primarily by older operating systems and not used by modern operating systems. On newer Intel 64 processors, A20M# may be absent."

Originally Posted by Thomas Richter

I wouldn't be so sure... this was mostly a market decision with IBMs architecture getting more market share. As always, it's not the best system that wins the market, but "who is first to the market". Look at VHS vs. Betamax vs. Video2000. The worst system made the win, until the next "quantum leap" happened and tape-based video recording systems became all obsolete.

Probably something similar happens now, probably arm is taking over. I wouldn't miss the A20 gate and the "too many modes" of the intel CPUs.

Moto just gave up its good positions maybe because smart people criticized the VAX-like 68020 too hard.

What is wrong about many modes? IMHO they are quite logical solution in any evolutionary development.

[BippyM]

IMHO maybe starting a new thread, based on the exact same topic, which is an actual continuation of the same topic is perfectly acceptable. Anyone coming into thread number 2 doesn't need to go searching for the first thread to find out what is going on. The threads are merged, they are staying merged, so please be gracious and accept that!

Originally Posted by litwr

IMHO maybe it is not the best idea to combine two threads because
1) the combined thread has become so large that it is very difficult to navigate its content;
2) the first thread was stopped about 26 months ago;
3) people who are participants in both threads now have a slightly different attitude to many of the discussed topics than they did 2 years ago.

[Bruce Abbott]

Originally Posted by litwr

Indeed, $20,000 was a wrong number for the case. It seems that systems based on the 68000@12MHz and 80286@6MHz could have almost identical prices in 1984 though the 68000 systems were more costly.
I didn't make a mistake intentionally - I rather exaggerated too much.

Thanks for admitting that. This is what happens when you try to push an agenda rather than looking at the subject dispassionately.

Wikipedia has a lot of errors but it doesn't mean that Wikipedia writers are disrespectful for their readers.

Usually if that happens it gets flagged and someone edits the wiki. For better or worse that doesn't happen here, so we must try to avoid being disrespectful. Some of your advocacy comes out sounding disrespectful to Amiga users because you make a big deal about anything you see as wrong with the Amiga while hand-waving away PC issues. The truth is that no computer system is perfect, and which you think is 'best' depends on what criteria you consider more important. You should respect the fact that other people's priorities might not match yours.

So I ask you again to help me make code for the 68000 faster and get better results for this processor.

If you are serious then perhaps you should open a new thread for that. We will be happy to help, so long as you stick to the task and don't off on a rant about how bad you think 68k is compared to other CPUs.

Just check the information I provided for you. Let read it again.
"Quadra 700 with the 68040@25MHz has 0.89 CPU performance value on Speedometer 4.02
The same computer running with the PPC@50MHz has 2.59 CPU performance value on Speedometer 4.02
So it is easy to conclude that the PPC is about 45% faster than the 68040 at the same frequency".

Mac performance doesn't interest us much, except to note that we can emulate a classic Mac faster on an Amiga if we want to (not very often). And since we really don't care we won't bother trying to check up on yet another dodgy benchmark comparison.

There were a lot of other computers: the Apple II, Commodore 8032, Atari 800, Tandy TRS-80, TI-99/4A, CP/M computers. However, the IBM PC was the best among them.

This is where you invite criticism. The IBM PC had some good stuff, but also some bad stuff - just like the others. To decide that it is empirically 'the best' based on your own personal criteria is disrespectful to those who had a different experience.

Many of us were disappointed with real-world performance of the original PC, considering the hype and the premium price IBM was selling it for. My Amstrad CPC664 was much nicer and better value for me, and I say that as someone who did buy a real IBM when I could get it at an acceptable price. It was quite a shock to discover that the Amstrad actually beat the PC on some tests, despite having a 'slower' 8 bit CPU. And as I found out recently, an 8MHz 8086 isn't much better.

[chb]

Originally Posted by litwr

Thank you. I posted somewhere in this thread a link to the site of the person who created the Sage and Stride computers. It is a very interesting story which tells us that computer business is not just based on technology.

True. IMHO also an example that it's often not the best technology that wins in the end.

Originally Posted by litwr

This man had to leave his company in 1984. The Sage computers were quite known, we have Wiki page and other materials about them. But information about the Stride is very difficult to find. It seems that only few of them were produced and they were sold mostly in Europe. The Pinnacle was even more rare. Rod Coleman wrote that his company produced only about 10,000 units of all Sage models. So one can estimate that the Stride and later Pinnacle computers had much less number of total units made, maybe less than a thousand.

Sageandstride.org has quite some information about both Sage and Stride Micro, and a bit about Pinnacle. I agree that they were much less common than the IBM PCs/ATs, and were rather developer/custom application systems than office computers. Those 1000 units for Stride seems pretty low to me, how do you arrive at that estimate?

Originally Posted by litwr

The ad you mention says that 12 MHz is only an option and it is 12 not 12.5 MHz. This ad is also dated by 1985 not 1984. So you can notice that it is easy to make an error.

Base model 8 Mhz $2900 + 12 MHz option $500 is less than $3500 according to my math. The ad is from spring 1985, but the blog post by Rod Coleman states that the Stride was available in 1984 for that price. Oh, and while clocked at 12 MHz, it's safe to assume they put the 12.5 MHz version in there.

Originally Posted by litwr

I agree that the price could be below $3500 for a base model with 256 KB RAM and one floppy drive. But it was rather an exotic option, I thought about a mainstream work station class computer with several megabytes of RAM and this option was above $10,000 and even $20,000. Indeed, $20,000 was a wrong number for the case. It seems that systems based on the 68000@12MHz and 80286@6MHz could have almost identical prices in 1984 though the 68000 systems were more costly.

Well, that's a bit of a dishonest argumentation (maybe not intentionally). First, you compared the price of a full blown workstation computer ($20k would get you a HDD and several MB of RAM, as you state yourself) to the price of a naked AT with a floppy and 256k of RAM. Then I give you data that shows that a 68000@12MHz system could be bought for considerably less money than the IBM AT in 1984, which leads you to the conclusion that prices "were almost identical, though the 68000 systems were more costly". Yes, PC clones got much cheaper in the following years, but this was not your original statement

In itself that's a quite unimportant detail, but it's this repeated pattern to bend the facts ever-so-slightly (or not-so-slightly) in the direction you prefer that makes this discussion a bit tiresome, even so I really appreciate opinions that differ from the mainstream. So, please, keep your opinions, but mark them as opinions and apply a bit more of scientific rigor to your statements.

[meynaf]

Originally Posted by litwr

I meant that MOVE from SR should not have read arithmetic flags at all.

Now that's another story. If you want SR and CCR to be completely different registers, you have to know that saving/restoring a second register for interrupts/exceptions would have cost extra cycles for basically nothing.

Originally Posted by litwr

How can I reject a result? If you can make the procedure smaller it will be a fact. However this shouldn't degrade the procedure speed. How could I ignore facts? I think you mean pi-spigot implementation which uses stack memory. It was accepted but as a trick only, a conventional program can't use such tricks. So this implementation shows that some strange tricks can help the 68k gets a better code density. It was a very interesting result. Many thanks to its author.

How can you reject a result ? Reread this thread.
I still have the memory of your pi-spigot program where you removed features just to show shorter x86 code.
(As a side note, the exe of the full version with duration shown is 313 bytes on my VM.)

Originally Posted by litwr

I am really interested to make Xlife-8 code better. I can repeat "any help is welcome". Thank you in advance.

Open a thread for that. There are coders here.

Originally Posted by litwr

What a strange claim! Indeed any code can be optimized. Is it something new for you? So I ask you again to help me make code for the 68000 faster and get better results for this processor. It can show the 68000 and 68020 superiority. I am always glad to find an opportunity to improve programs in my project pi-spigot, Xlife-8, ... So if you believe that the 68k can show better speed just try to show it.

There is a difference between code that can still be optimised and code that's largely sub-optimal. If i really wanted to show good code for 68k i would have to rewrite it fully.

Originally Posted by litwr

Join open source projects. You can also complain it is difficult to be a pirate in our time.

This has nothing to do with open source or piracy.
I can port Atari ST, Mac 68k, even Oric game to Amiga. First step is full disassembly and i just can't do that for e.g. a PC DOS game. For a Windows game, even worse.

Originally Posted by litwr

Sorry, I don't understand. What do you mean?

Sorry, bad translation of french appel de porte. I meant, CALLM/RTM somehow look like x86 call gates, at least conceptually.
https://www.technovelty.org/arch/ia3...tem-calls.html

Originally Posted by litwr

I hardly call two carries a shortcoming, it is just an oddity which shows how strangely Moto spent its transistor budget. Maybe you are right about this ARM shortcoming, I wrote about it quite overtly in my blog entry more than two years ago - - so you again write wrong thing about my blog.

Where in your blog do you write about the arm having as big shortcoming the inability to operate directly on memory ?

Originally Posted by litwr

I wrote about the modern ARMs, indeed, the old good ARM can't do unaligned accesses. So I wrote rather misplaced information. Sorry.

So you compare modern ARMs with old 68000, i see.
Note that i am not sure aarch64 actually allows misaligned accesses. As most Risc cpus don't.

Originally Posted by litwr

It is your clear miss again. MOV RCX,[RBX] is a quite ordinary move from memory to a register.

The 68k obviously can do ordinary move from memory to a register...
A 80386 also can't do MOV RCX,[RBX], but apparently this isn't a shortcoming for you.

Originally Posted by litwr

Just check the information I provided for you. Let read it again.
"Quadra 700 with the 68040@25MHz has 0.89 CPU performance value on Speedometer 4.02
The same computer running with the PPC@50MHz has 2.59 CPU performance value on Speedometer 4.02
So it is easy to conclude that the PPC is about 45% faster than the 68040 at the same frequency".

You can not conclude anything for a single example randomly fetched on the internet.
Besides, the situation isn't the same, the PPC had onboard L2 cache.
Change compiler settings, or switch to another compiler, and you can easily get 50% speed difference.
In addition, compiled 68k code can be rewritten in asm to be at least 2x faster (my record is 14 times).

Originally Posted by litwr

What a crazy idea! There were a lot of other computers: the Apple II, Commodore 8032, Atari 800, Tandy TRS-80, TI-99/4A, CP/M computers. However, the IBM PC was the best among them.

These computers aren't 'PC'.
And no, the IBM PC was clearly not the best among them. It might have had faster cpu (a still questionable situation) but the rest was poor.

Originally Posted by litwr

If you are serious why didn't you write an article about your "discoveries".

Perhaps because i have more interesting things to do than to prove the obvious.

Originally Posted by litwr

Agreed but why did they spend transistors for this zero effects?

The transistor cost is also almost zero

Originally Posted by litwr

Optimization can make code several times larger. So it can explain this difference quite perfectly.

For small routines yes, but not for a whole program. As most of a program's bulk is usually not loops.
But, feel free to disassemble them and show us why the x86 code is so big

[Thomas Richter]

Originally Posted by litwr

Yes, it is my point too. MOVE from SR must have read only system flags and we should have had MOVE from CCR since the 68000.

That would be another design, though remember that upon interrupts, both must be saved and restored jointly.

Originally Posted by litwr

It is a direct consequence of 16-bit architecture. You know that other 16-bit processors used similar architectural solutions.

No. It is the consequence of indequately upscaling a 16-bit architecture to a 24-bit architecture. If this had been done properly, registers would have become wider, plus some MMU-like mapping for code operating in legacy mode to the address space. Actually, intel did just that later on.

Originally Posted by litwr

The 68000 is actually a 32-bit processor with 16-bit ALU, this makes it better to handle larger memory amounts than 16-bit processors.

Correct, and that's also a sane design to address this problem (while keeping the ALU small and allow to upscale it later).

Originally Posted by litwr

I can only repeat that the 8086 is a 16-bit processor and you don't know a better way to make a 16-bit processor.

The point is, the time for 16-bit processors was over, and intel had to upscale it. But, instead of making the architecture wider, they came up with a kludge, and I certainly know better ways how to upscale a processor.

Originally Posted by litwr

Actually the 8086 was in many ways the best 16-bit processor.

By whose means? As far as the instruction set is concerned, the Z80 had more to offer, like string or memory copy functions.

Originally Posted by litwr

You can even write that Ancient Greeks could design a perfect 1024-bit processor and use it. Technologies became cheap enough for making 32-bit systems only by 1985. You ask Intel "do nothing because in the future you must do a better thing". It sounds very odd, doesn't it?

It sounds very odd that intel came up with such a needless kludge at a time other 32-bit processors were already in the market.

Originally Posted by litwr

It was rather our talk with meynaf. I ask him to help me to make Xlife-8 faster and try to prove that the 68000 code density can be better for Xlife-8 main algorithm than code density of the 8086.

I cannot really tell. I would guess as long as you can get away without prefixes, the 8086 code may be more compact. Unfortunately, intel wrapped more and more duct tape and chewing gum around their architecture, so more prefixes piled up.


[QUOTE=litwr;1464209]



meynaf likes MOVEM, I also find it quite useful. Why do you think that MOVEM is rather an extra?
[/QOUTE]
Because you could work without one, and it would create less trouble with exception handling. Consider the case of an exception within a movem. Either the exception has to be delayed (and thus comes late) or the movem has to be aborted. This necessarily means that the exception has to store enough information to continue the movem, or that the movem has to be re-run, which means that writes (or reads) will be doubled. While that is OK for memory, it might not be not ok for memory-mapped I/O.


It is also more complicated for bus errors as either the movem has to precompute (by the numbe registers) which pages(!) it may touch and which have then to remain open, or you run again into the problem of either storing a long memory frame with the missing writes indicated (the 68040 does that) or you re-run the movem and then have to tolerate double writes (the 68060 does that).

Originally Posted by litwr

I wrote system boot routines and I know that the modern way to enable the A20 line is to use port 92h. There were other ancient ways using the keyboard controller or BIOS INT call. It was an external circuitry.

*Was* until it had to be moved into the CPU to keep caches consistent. It then necessarily became part of the CPU and cache design.

Originally Posted by litwr

They had to add some support for it in the 80486 and later processor because of caching. All this thing were made for DOS only.

No, for the bios boot procedure. It doesn't work without.

Originally Posted by litwr

It is all about 2-3 lines of typical code in this procedure. Its importance for software is zero!

And its importance for the architecture is huge, as it goes into the CPU, and into the cache design. It is just a pile of legacy kludges every intel CPU still carries around.

Originally Posted by litwr

I hardly call this even a quirk, it is rather a way to keep compatibility with OS which was very popular until 1995. BTW do you know that

A *quirk* you call something that affects multiple layers of the machine design because intel didn't want to throw this nonsense overboard early?

Originally Posted by litwr

Moto just gave up its good positions maybe because smart people criticized the VAX-like 68020 too hard.

Please leave it to others whether this was "smart" or not.

Originally Posted by litwr

What is wrong about many modes? IMHO they are quite logical solution in any evolutionary development.

Addressing modes? Because they have impacts on the design. Consider for example a move with double indirecton at both ends. move.l ([a0]),([a1]) may require a virtual memory system to keep as many as 8 pages open at once. Two for (a1), as a1 may be misalgned, two for [(a1)] as the pointer in (a1) may be misaligned, and the same goes for a0 again. Also note what the chip has to do if one of the pointers creates a bus or access error. Again, it is either re-run the instruction, tolerate double reads, or store enough context information in the exception stack frame to avoid this. In either case, exceptions are slowed down.

[Photon]

I'm new to this thread, but "people" chose Intel not because of Intel at all. It obviously helped Intel that PC buyers didn't care about the "hardware inside", the real question is how they couldn't tell the difference to other brands and still forked up big cash.

80x86 was some horrible extension of 8-bit and 680x0 was a CISC, i.e. "wishlist" CPU design. ARM showed the way early, and both Intel and Motorola adopted RISC, and probably spent millions and millions adapting their horrible designs...

Pentium is pure sh*t and 68060 is a beautiful CPU. But by this time idiots had paid $1500 for crap and hundreds more to expand it. Let's call it the IBM "ecosystem".

PowerPC and Alpha were interesting but remained so for the technical few.