Re: microcontroller programming -- how to begin


"David" <david@xxxxxxxxx> wrote in message
news:448155db$1@xxxxxxxxxxxxxxxxxx
Rich Grise wrote:
On Fri, 02 Jun 2006 20:17:52 +0200, David wrote:

Ken Smith wrote:
In article <447f2e71$1@xxxxxxxxxxxxxxx>, David <david@xxxxxxxxx>
wrote:
Ken Smith wrote:
[....]
It's true that the AVR, like the PIC and the 8051, are Harvard,
while the x86 is von Neumann. But that's only one aspect of the
architecture - in many other ways, they are completely different.
Ok lets discuss those differences.

And since you are happy count the PIC and AVR as similar because
they both have registers
Yes, they both use the concept of the register. ie: a very special
memory location that can be used in ALU operations. There have been
a few attempts at processors where there are no "registers" in that
all operations took data from RAM and put the result into RAM. IIRC:
The Intel 432 was an example of this.
or because they both execute instructions sequentially,
I was thinking of a bit slice design that did not have this property
when I wrote that. In some "very long instruction word" designs, the
address of the next instruction in encoded in each instruction.
These machines are light years different from things like PICs or
x86s.

There are certainly processor architectures that use significantly
different architectures, making the PIC and AVR seem similar in
comparison. I have read of several processor designs (some only
theoretical, others made in practice) that use two, three or four
stacks instead of having any data registers. But I think it's
reasonable to divide architectures in groups according to the number
of general purpose registers. RISC architectures like the MIPs, PPC
and AVR, along with hybrids like the MSP430 and the 68k have multiple
orthogonal registers. Accumulator-based designs like the PIC or the
COP8 have a single main register. A third group has several
specialised registers, like the x86 and the Z80. And a forth group
has no registers at all, like the MARC4.

I guess how "different" two architectures are depends on what you see
as important in the design, and is always a subjective measure. But I
think most people who have looked at the ISAs for the PIC, the 8051
and the AVR will see each as very significantly different, with the
8-bit width of the ALU being about the only common factor.

I got nostalgic for the 6502; it's a very neat processor for little
stuff;
it's got like 256 general purpose registers called "page 0" which live
in
RAM, right next to the 256-byte stack. So, I went looking, and there's
VHDL and Verilog cores for it all over the place! (I made a keyboard
interface with one once. :-) )

Cheers!
Rich


Page 0 on the 6502 is not a set of registers - it is a page of memory
which can be accessed with shorter (and therefore faster) addressing
modes than the rest of the memory. The 6502 has one general purpose
register (the accumulator A), two index registers (X and Y), and a stack
pointer, status register and program counter.

But I agree it's a very neat processor - it helped make the BBC one of
the fastest and most advanced home micros available in its day. The BBC
was significantly faster than the spectrum, even though the 6502 on the
BBC ran at 2 MHz (IIRC) on the first systems, and is pure 8-bit, while
the Z80A powering the spectrum ran at 3.5 MHZ (again, IIRC) and can do a
fair amount of 16-bit arithmetic directly. Part of this was the 6502
(it used fewer clock cycles per instruction than most contemporary
processors, and had a pipelined instruction decoder), and part of it was
the genius of the Acorn engineers (the same bunch that gave us the ARM).
If you want to see some impressive coding, look for a listing of the
BBC's MOS rom - to save space, the various tables frequently overlapped
with each other and with executable code!
Generally, the 6502 'models', came out in general at about half the clock
rate available from the Z80 examples at the same time. The reason was a
totally different internal architecture. The Z80, used the clock divided
down into four internal phases to perform the instruction fetch, etc.. The
6502, used the two halves of the incoming clock cycle, as it's internal
phases. It was a neat architecture, but shows the problems of comparing
'clock rates' when different processors are involved.
The same difficulty is true when looking at 'registers. The PIC, is a good
example of how complex this can be. It has only a single working register,
but has a large register map, built into it's RAM space, some of which
function like registers implemented on other processors. For instance,
there is effectively an 'index' register, status register etc., all built
into the standard memory area. The biggest problem it has though, is a
large lack of ability to distinguish these 'core' control registers from
the others (such as ones that perform I/O, or are just being used for
storage), and no quick ability to save/restore the core 'set' (there is
now an ability to automatically save the status, and page select
registers, but nothing to do the same for table addressing registers
etc.). The difference this makes is major. For example, the Z80 (and
several other processors at this time), had a single instruction, allowing
it's 'core' set, to be swapped with a second set. This allowed very fast
interrupt servicing, with just the call to the handler, swapping of the
register set, the actual interrupt code, and a similarly quick return. I
wrote a system, which handled synchronous data at over 250000bps, on the
Z80 at 6MHz, which was still happily in commercial use until recently. It
used the Z80, to feed the data into a dual port memory (implemented using
a very early FPGA), and had run for about 20 years, in several hundred
sites, without missing a beat. The new replacement, using a modern
'embedded' PC (not my design), needs over 1GHz on the processor clock, to
achieve little more, and had major problems on the first few releases, in
keeping up with the serial interrupt rate, because of the huge overhead
involved with the latter processor when handling interrupts. This can be
seen very commonly on the PC, where serial ports in each generation, have
needed larger and larger buffers, if data is not to be lost, despite the
huge processor clock rates...

One of my first real assembly programs was for the 6502 - it was a
disassembler, running on the BBC micro (actually it was partly assembly,
partly Basic).
There were other nice features to. The two phase clock, allowed you to
perform things on memory in the second phase, while the processor accessed
the same area in the first. I built one of the commercially available
'second processor' cards for the system, which used this ability.
The code, really illustrates the difference, when memory, is a rare
commodity, costing a lot per byte, and it is economically worthwhile, to
actually 'think' about how best to use it, instead of just shovelling in
more memory, which at times seems to be the approach today...

Best Wishes


.

Relevant Pages

  • Re: Well, _that_ didnt work.
    ... orthogonal instruction sets. ... which registers can be combined in operations, ... of memory addressing modes which can all be used in any memory reference ... memory controller, so a memory reference that isn't an instructionn ...
    (alt.sysadmin.recovery)
  • Re: non load/store architecture?
    ... fast memory. ... Instruction decoding logic is large and slow, ... The lack of registers means much ... instructions with memory operands ...
    (comp.arch.embedded)
  • Re: Beneath assembly
    ... a single opcode. ... structure depends heavily on the processor type (ie, a RISC instruction ... Once these binary opcodes are created, and in memory, how the processor ... flip-flops become registers, and then shift registers, bit-adders ...
    (comp.lang.asm.x86)
  • Re: Blast from the past... Z80!
    ... If you enjoy moving data from here to there and back. ... b are memory or registers. ... Consider a 200 MHz CPU, runing an instruction per clock from cache, ... with 16 32-bit registers and MAC instructions. ...
    (sci.electronics.design)
  • Re: Code review request: small optimization to localtime.c
    ... Now, an optimizing compiler might put a and b into registers, ... Also, on some architectures, the caching structure may cause writes ... parts of memory, if you're unlucky. ...
    (freebsd-arch)