> If one overwrites PIC16FXXX PGM memory with
> an illegal opcode, what does the PIC
> processor do? reset? ignore it?
Keep in mind that the PIC is a RISC microcontroller. In a CISC micro, there
is a program embedded in the part to interpret opcodes and do what they say.
In that case, the embedded program can decide what to do with an illegal
opcode, and in a typical CISC processor, it generates an exception to be
handled by the operating system.
In a RISC part, there is no such program. The operation is controlled
directly by gates which must be driven by the bits in the instruction.
Certain bits or combinations of bits cause data to flow from one internal
register to another resulting in the behavior that we see as the instruction
set.
There really are no illegal opcodes in the PIC, but there are undefined bit
combinations that will result in undocumented behavior. Some folks have
explored these undocumented bit combinations, and I seem to recall some
people finding some of them to even be potentially useful.
The problem, of course, is that since they are really side effects of the
intended behavior, they are not likely to be consistent from model to model,
in fact, there really is no reason to expect them to be consistent from one
die revision to the next, so there is a pretty strong disincentive to using
them, to say nothing of the practical problem of figuring out what they do.
Kind of disappointing, isn't it. Really no 'secret' super instructions,
just bits causing data to fall through the registers in unplanned ways,
possibly, but not probably, causing something to happen once in a while that
might be useful, but probably different tomorrow!
As far as what to put in the unused space, keep in mind that an unexpected
jump off into unused memory is not necessarily going to have the PCH
properly set, so your goto 0 isn't always going to automatically restart
your app, at least in parts with more than 2K of Flash. For debugging
purposes, you might consider filling it with something that you can detect,
but I think most people leave it filled with addlw -1 (0x3fff).
> Keep in mind that the PIC is a RISC microcontroller. In a
> CISC micro, there is a program embedded in the part to
> interpret opcodes and do what they say.
>
> In that case, the embedded program can decide what to do with
> an illegal opcode, and in a typical CISC processor, it generates
> an exception to be handled by the operating system.
>
> In a RISC part, there is no such program...
What ??
Of course any desent RISC processor (Power, Alpha, Sparc, whatever)
has traps for "illegal opcodes", "divede by zero", "executing prived
instructions by un-prived code" and so on. And there are trap-vectors
in program space (just as "interrupt vectors) so it can jump to
whatever routines the OS want's to. This has *nothing* to
do with the CICS vs. RISC issue.
> The operation is controlled
> directly by gates which must be driven by the bits in the instruction.
> Certain bits or combinations of bits cause data to flow from one
> internal register to another resulting in the behavior that we see as
> the instruction set.
No differences between CICS and RISC there.
> There really are no illegal opcodes in the PIC, but there are
> undefined bit combinations that will result in undocumented
> behavior.
> Of course any desent RISC processor (Power, Alpha, Sparc, whatever)
> has traps for "illegal opcodes", "divede by zero", "executing prived
> instructions by un-prived code" and so on. And there are trap-vectors
> in program space (just as "interrupt vectors) so it can jump to
> whatever routines the OS want's to. This has *nothing* to
> do with the CICS vs. RISC issue.
Actually, there is quite a difference. RISC processors catch -some-
problems. As you point out, many have traps for things like divide by zero,
and some of the more elaborate RISC processors catch some illegal
instructions. But it is very difficult for a RISC processor to catch all
illegal instructions, indeed, it takes a very complicated RISC processor to
catch most of them, and that sort of defeats the point, doesn't it. And of
course, most of the modern processors which market themselces as RISC are
actually CISC processors with RISC-like instruction sets.
> No differences between CICS and RISC there.
Actually, there is quite a difference. In a CISC processor the instructions
are essentially interpreted. The processor's microcode itself runs much the
same way as the user code in a RISC processor, but that program decides what
to do with the instructions. Typically, the microprogram instruction word
is quite large, hundreds of bits wide, in order to manage all the gates
necessary to implement the large capabilities of these processors. But by
having an embedded program, rather than a (relatively) simple array of
gates, actually implement the instruction set, it is quite simple, indeed,
pretty much necessary, to catch all the illegal opcode combinations. In a
true RISC processor like the PIC, it is actually pretty difficult to catch
illegal instructions.
Now, back to the Power, SPARC, Alpha etc. A funny thing happened in the late
80's early 90's. The original RISC processors resulted in great
improvements in compiler optimizations that made RISC a very popular
buzzword. This prompted the development of CISC architected parts like the
Alpha to implement RISC-like instruction sets to take advantage of the
compiler optimizations, as well as the marketing hype. I believe the
original SPARC processors actually were RISC architecture parts, but I have
no data on more recent SPARC's. I'd be kind of surprised if they were still
actual RISC processors. Originally, Alpha was a CISC processor marketed as
a RISC.
Later on as M$ began to take over the world, compiler work shifted to CISC
environments, and the performance advantage that RISC got from the compiler
got lost. Also, processor speeds exploded, but external bus speeds didn't
keep up, so the raw performance advantage of the RISC architecure in general
purpose applications also disappeared. Now, honest-to-gosh RISC processors
are pretty much relegated to embedded applications where the code is finely
hand tailored and the applications tend to be very price sensitive.
> > There really are no illegal opcodes in the PIC, but there are
> > undefined bit combinations that will result in undocumented
> > behavior.
>
> And what is the differense ?
The difference is that an illegal opcode is a defined thing with a defined
behavior - typically, push the status on the stack and jump to location xxx.
An undefined opcode has undocumented behavior.
John J. McDonough <.....mcdKILLspam@spam@is-sixsigma.com> wrote:
> Jan-Erik Soderholm <jan-erik.soderholmKILLspamtelia.com> wrote:
> > No differences between CICS and RISC there.
>
> Actually, there is quite a difference. In a CISC processor the
> instructions are essentially interpreted.
I think you missed the point Jan-Erik was trying to make. I don't know why
you insist that CISC = microcode, but it's a very old-fashioned notion.
Modern CISC processors, the x86 architecture being the obvious example,
execute *more* than one instruction per clock though heavy pipelining and
superscalar hardware architecture. There is *not* a microcoded interpreter
in there doing it all.
Looking up illegal opcodes (on any architecture) can actually be done by
a relatively straightforward and tiny (relative to the rest of the logic)
PLA in parallel with the rest of the instruction decoding and execution
pipeline.
In fact, I could turn that around on you: If the PIC is truly a RISC
(no microcode, according to you), why does it take four clock cycles to
accomplish anything? (only half :-)
>
>Looking up illegal opcodes (on any architecture) can actually be done by
>a relatively straightforward and tiny (relative to the rest of the logic)
>PLA in parallel with the rest of the instruction decoding and execution
>pipeline.
>
>In fact, I could turn that around on you: If the PIC is truly a RISC
>(no microcode, according to you), why does it take four clock cycles to
>accomplish anything? (only half :-)
And the AVR, most instructions in one cycle, but it's considered CISC,
relative to the PIC.
IMHO, RISC and CISC are just marketing verbiage, no more significant than
"super" or "new and improved".
Ever notice how every brand of aspirin is better than all the other brands?
> > In fact, I could turn that around on you: If the PIC is truly a RISC
> > (no microcode, according to you), why does it take four
> > clock cycles to accomplish anything? (only half :-)
>
>
> And the AVR, most instructions in one cycle, but it's
> considered CISC, relative to the PIC.
And of course (and maybe implied) that (clock cycles per instr)
has nothing to do with the CISC/RISC issue.
> IMHO, RISC and CISC are just marketing verbiage, no more
> significant than "super" or "new and improved".
Well, after all, the "C" in CISC stands for "complex" and the
correspondig "R" in RISC stands for "reduced", right ?
CISC was nice when a larger part of the software (even enduser SW)
was written in assembler. Look at VAX MACRO-32 or the assembler
on IBM mainframes. On the VAX many simple Fortran operations
compiled into single machine instructions (incl many string operations).
On the IBM mainframe it's the same with COBOL operations vs. machine
code. It's easier to write assembler for a CISC processor.
On the RISC processors very little (apart from OS kernel stuff) is
written in assembler. So the compilers take care of generating all
the additional instructions needed on a (typical) RISC processor to run
the same task as on a (typical) CISC processor.
The CISC/RISC issue is a question about how the processor
"interface" looks like to programers and compilers (that is, if
the intruction set is "complex" or "reduced"). It has little to
about if they have "traps" for illegel opcodes or not, just to get
this a little closer to the original topic... :-)
> In fact, I could turn that around on you: If the PIC is truly a RISC
> (no microcode, according to you), why does it take four clock cycles to
> accomplish anything? (only half :-)
Likely because a read-modify-write style automaton architecture without
fully shadowed or buffered or pipelined registers takes that many cycles
at a minimum to run head-to-tail without race and timing problems afaik.
A shadowed one should be able to do it in one (Scenix ?).
Otoh I was just reading that last year a clockless ARM version appeared.
It promises to run twice as fast for 30% of the power. ARM cpus power
some *nix powered consumer routers/firewalls and several palmtop
devices. It uses asynchronous logic throughout. I have not yet read the
real report, just a newsflash.
> In fact, I could turn that around on you: If the PIC is truly a RISC
> (no microcode, according to you), why does it take four clock cycles
to
> accomplish anything? (only half :-)
Because multi-stage execution versus single-stage execution has nothing
to do with RISC versus CISC.
RISC versus CISC is a non-issue these days. Some RISC CPUs interpret
some of their rarely used instructions, some CISC machines translate
their complex instructions into RISC-like instructions. A 14-bit PIC
might be called RISC because it has only a few instructions, but an 18F?
or a 30F?
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
telia.com>
