Re: Used interrupts on both 68k & PIC, want 68k w/onboard memory & JTAG/BDM



linnix wrote:
From the very start, the 68k had a 32-bit programming architecture.
For cost reasons, the implementation used a 16-bit ALU and datapath, but
all the registers were 32-bit, and all instructions supported 8-bit,
16-bit and 32-bit widths (even though the 32-bit versions took twice as
many clock cycles). This meant that when 32-bit ALUs became
economically feasible, the 68k just got faster with the same software,
unlike the x86 architecture that got seriously ugly in the move to 32 bits.

In a way, we have to thank the x86 marketer for beating the 68k.
Otherwise, many programmers would stay with assemblers and C would not
be as popular. C masks out the ugly x86 architecture.


People have used C on the 68k for about as long as there has been C (68k cpus were a popular choice for early unix workstations such as Sun's first machines, unlike x86 which only gained serious *nix popularity with Linux. It was also the original target for gcc). Writing a C compiler for the 68k is peanuts compared to writing one for the x86, since the 68k has a wide set of mostly orthogonal registers, plenty of address registers, and addressing modes ideal for C. Getting the best out of an x86 device is a black art, and it was a long time before C compilers could compete with professional x86 assembler programmers. So I expect most serious x86 development was still being done in assembly long after C (and other high level languages) were standard on the 68k (the Mac OS being a notable exception, written mostly in assembly for some reason).

The legacy of assembly on the x86 is one of the reasons why the instruction set is so hideous - it has had to keep 100% binary compatibility because you can't just recompile your assembly code for a new architecture. The 68k architecture, on the other hand, has seen many binary incompatible changes (such as the removal of rarer addressing modes) to improve efficiency.
.



Relevant Pages

  • Re: Confusing regarding SI and DI
    ... I'm trying to understand how to go about using SI and DI with other registers for indexing. ... I have seen different code examples that use and in brackets, but I'm afraid I don't quite understand how to do the above in x86 yet. ... The code uses AL which is a portion of AX. ... used by x86 assemblers. ...
    (comp.lang.asm.x86)
  • Re: Machine code summary
    ... > The main problem with your background will be to downscale but I have ... Lack of registers; 8 is a bit limiting, ... You're going to find quite a lot of the x86 ... assemblers much weaker, especially in the area of macro support. ...
    (comp.lang.asm.x86)
  • Re: non load/store architecture?
    ... Programmers can write great code on a RISC ... Especially in a PC marketplace dominated by the x86. ... Lots of registers and an orthogonal instruction set are important - both have these. ... The lack of registers means much more memory IO, which causes stalls and requires complex scheduling. ...
    (comp.arch.embedded)
  • Re: Intel publishes Larrabee paper
    ... Using x86 as the base it is understandable that the third vector operand ... 32 registers times 4 sets, plus some rename registers and you are ... visible registers your actual register set becomes large, ... The die size tradeoffs of 4 way multi threading is mostly about reducing ...
    (comp.arch)
  • Re: VMS Software, Inc. announces agreement to continue development of OpenVMS and Layered Products u
    ... Other reasons I remember for x86 virtualisation included: ... These three reasons pretty much sum up our move to VM's. ... Longstanding VMS customers are used to those last two being sorted ...
    (comp.os.vms)