Hot answers tagged

67

Attention: The part about the 4-Way Set-Associative Branch Cache has been rewritten, as my original explanation was complete bogus (*0). What a big and and wide question. Fast Answer: No CPU can handle alternating branches equally well. Slow Answer: Work your way thru the 68060 User Manual. It's all there. Short Answer: Having said that, your question ...


51

On a typical 6502, Z80, or 68000 system, it's possible to predict very precisely exactly how long a piece of code will take to execute. The same is true, incidentally, of many small microcontrollers produced today. In many cases, this allows some operations to be done more efficiently than would otherwise be possible. For example, if both function-control ...


43

I’m not sure the separate cache was “obviously better” back when the Intel designers were working on the 80486, at least, not to the designers in question. But “better” might not even have been much of a factor. The design history of the cache systems in Motorola and Intel CPUs is quite different, which can explain the different approaches used in the 68040 ...


36

The premise in the question is incorrect. There were such chips. The question also fails to allow for the way that the silicon-chip industry developed. Moore's Law basically said that every 18 months, it was possible to build chips with twice as many transistors for the same amount of money. The 6502 (1975) is a mid-1970s design. In the '70s it cost a lot to ...


27

This paragraph in Wikipedia really is no candidate for the best entry-of-the-year award. It seems to be comparing Apples with Oranges. (Or rather starts talking about CPUs, then commences on PCs vs. "something else", i.e. system architecture). A comparison of interrupt latency and predictability thereof doesn't make much sense on CPU level - It ...


23

There are a few incompatible changes, but after the 68010, most of them are surmountable (with a performance penalty) or would only affect operating systems, not applications (at least, not applications written to spec, with no invalid or undocumented opcodes or addressing modes). 68010: introduced support for the MC68451 MMU; “MOVE from SR” became ...


22

It's the simplicity. Under modern general purpose operating systems, you don't usually have hard real-time guarantees. Too many things are going on. Context switching is slow. Interrupts are slow. The kernel is often not fully pre-emptable. On top of all that, modern hardware incorporates features like speculative execution, extensive pipelining, ...


21

Stephens Answer already carries most implications, so this is merely an add-on. First to keep in mind is that the 68k was way more in need of a cache than x86 CPUs, as its memory access was in line with execution, while the x86 prefetch buffer used 'free' cycles to read ahead, thus utilizing the memory much better than the 68k could do (*1). Next, it ...


16

The byte select signals select the low byte or the high byte or both. The 68000 has instructions for reading or writing words (16 bits) and bytes. In the latter case, it needs to be able to tell the world which half of the databus it is reading or writing. According to the 68000 user manual (table 3.1), when the process is reading or writing the data bus ...


16

The 65816 was close to the bare minimum of a 16 bit processor. It was primarily used where compatibility with existing 6502 code was needed, such as with the Apple IIgs. It was also used where the designers of a new 16-bit system were already familiar with 6502. This is probably why the SNES has the 65816, given the NES had the 6502. By the time the 32 ...


15

The 68k family is largely compatible between all the members. "Normal" application code can be written to easily run on all the members, unchanged. There are, however, a number of subtle differences and pitfalls to watch out. Some instructions were made privileged after the 68000/68008/68010, so are only accessible in supervisor mode (notably MOVE SR,<...


14

The memory indirect [pre|post]indexed addressing modes were basically direct support on CPU level for 2-dimensional arrays (which are inherently suitable to describe printed (pixelated) pages in various scalings). The programmer builds a table of row addresses in memory, and the CPU can directly access data in such tables by instructions like MOVE.L ([10, ...


12

Half a year ago, I've started a M680x0 port of LLVM. It is still at an early stage, but currently it is able to emit linkable/relocatable (no tls) object files that can be linked with GNU ld against glibc or newlib. ISA is limited to M68000 but is easily extensible. Also C++ support is rather questionable but if you are familiar with LLVM you can add it. If ...


10

There are three principal reasons: 1: Realtime software demands CPUs whose execution time is highly predictable. That is true mostly of CPUs without speculative features such as caching and dynamic branch prediction. Some modern CPUs (eg. ARM Cortex-R series) are specifically designed to provide this property. 2: Low interrupt latency and overhead, on the ...


9

I don't understand why western design centre made the 65816 a 16bit upgrade to the 6502 but commodore semiconductor group/MOS technology didn't make their own variant For one, the 65816 is only a 16 bit CPU in a very restricted way. All external transfers are still 8 bit wide and address expansion is rather clumsy. The main improvement wider architectures ...


8

Not an answer, but my contribution (found here, credit to witbrock@cs.cmu.edu): DIVS,DIVU - The divide algorithm used by the MC68000 provides less than 10% difference between the best and the worst case timings. MULS,MULU - The multiply algorithm requires 38+2n clocks where n is defined as: MULU: n = the number of ...


8

The extreme example is pure floating point calculations. Analogue electronics simulations, some kinds of 3D graphics rendering, statistical machine learning, huge spreadsheets, and so on. The comp.sys.m68k FAQ gives 264 kFLOPS for the 68882 at 25 MHz. The 68030 runs about 8 MIPS (integer) at 25 MHz. The source code for Linux's m68k floating point ...


8

As an example, years ago I installed a 25MHz 68030RC / 68851 / 68882 8MB accelerator in my A1200. First thing I did was use Realsoft Real 3D 1.x ray tracing program to render the teapot project. I rendered it using the standard program(1), then the FPU version. From what I remember, using the FPU version of Real 3D, the speed up was about 3 to 4 times faster....


7

The signals are there so in byte addressing mode the 68000 can read and write individual bytes. From memory UDS means that valid data is on bits 8..15 of the data bus and LDS means that valid data is on bits 0..7 of the data bus. In contrast a 8086 family part calls LDS A0 and BHE for the other bits. In practice on an AT architecture machine this is a ...


7

Simple answer: Because there is no default kernel defined within the loader. More in depth answer: Debian's m68k port is available for at least a dozen different machine (and CPU) architectures. This ranges from Apple, Amiga and Atari to embedded systems and rare workstations. Linux is a monolithic machine specific system. Unlike the PC, these 68k ...


7

Chips aren't either "RISC" or "CISC"; they fall on a spectrum between the two. The 68000 is less "CISC" than an 80x86, for example, and you could plausibly call the 6502 a somewhat "RISC" processor by the kind of definitions used that make the Amtel AVR "RISC." This isn't really very useful as a guideline for how much processing power you have. And MIPS ...


6

Although none of my databooks directly state how multiplication is done, we can infer several things from what they do say. My copy of M68000 8-/16-/32-bit Microprocessor User's Manual shows the execution times of the MC68000 multiply instructions on page 8-4: MULS 70(1/0)+* MULU 70(1/0)+* where 70 is the number of processor cycles, 1 means one read ...


6

In addition to the other excellent answers, sometimes the addition of caches could cause incompatibility. The 68010 had a single instruction cache that couldn't really cause any problems. The 020 increased this to 256 bytes, and later CPUs had both instruction and data caches which were even larger. The main fault encountered with instruction caches is ...


5

But is there any incompatibilities which could keep code written for the 68000 from being run the same way on a later model? Yes. Any 68000 program that used the "move from SR" instruction in user mode will trap on any later version of the processor from the 68010 onwards because the instruction was made supervisor only in that processor. This was to ...


5

Take a look at https://github.com/bebbo/amiga-gcc which are GCC 6.5 cross-compiler toolchains for Windows, Linux, and Mac OS X targeting AmigaOS 3. There's an ongoing discussion about it here. Edit: Thanks for the update, @bebbo!


5

Quadra 700's had a ROM-version which was 32-bit-clean (not using one byte out of all 32-bit-addresses anymore to allow addressing of more than 16MB RAM). Therefore it is quite unlikely, that anyone succeeded in running any System 6.x on a Quadra 700 computer. At least this version of System 6 needs to bring its own 24-bit-memory manager in RAM with it. Just ...


5

You can actually generate a "spurious interrupt" condition on the Atari ST with its MFP (68901) - Not on purpose, but rather because of a glitch in the Motorola 68901 - If you disable interrupts on the MFP exactly at the point when the CPU starts an IACK cycle (i.e with the last instructions before the /INT), it will not provide a vector, the CPU ...


4

While many of the performance capabilities of modern desktop processors intended to run multi-tasking operating systems are somewhat wasted in a real time context, they are not actually impediments. A soundly designed real time operating system uses hardware timers for the precise timing needs in terms of scheduling when code runs. Desktop operating systems ...


4

You should try chairwpz, if you didn't already. It manifests as as a decent toolchain for linux/MacOS. https://github.com/cahirwpz/amigaos-cross-toolchain


4

One approach you may be interested in that I recently saw somebody else using for working on a platform with no modern C or C++ compiler support was to use LLVM in its output-to-C-code mode, and then process the resulting C code through the original native compiler. This apparently meant they could use modern C and C++ features and they were able to benefit ...


Only top voted, non community-wiki answers of a minimum length are eligible