Morgan Olsson wrote:

> Den 2007-10-17 03:59:42 skrev <piclist3@xargs.com>:
>
> >
> >> If my understanding above is correct,  you mean the silicon bug
> >> may need  C compiler built-in fix. In that case, the user may
> >> be able to fix it by in-line assembly or some tricks, right?
> >No.  For example, look at errata #7 of the 18F452 B2 silicon.  The
> > first required work around is "Insert a data word of value FFFFh as
> > the first instruction in the destination of a CALL or GOTO."  How
> > would a user insert some arbitrary data at the beginning of a
> > function?  The function body begins with stack manipulation code
> > generated by the compiler, not user code.
> >
>
> Interesting.
>
> Is it possible to tell what Erratas are implemented?
>
> Do they implement workarounds for bugs in SPI, UART etc, there are a lot of them.
> It could lead to negative effects out od user control or intent.
>
> How do they handle different bugs between different chip revisions...?
> Do you tell it what chip revision you use?

Essentially that is what is done in the better compilers.

"It is the compilers job to make code that will run on the silicon"

In our compilers we look for solutions that will run on the
broadest spectrum of silicon possible and then it we can't
guarantee that the code will run we resort to processor specific
information communicated through the processor specific
header files.

This is a argument to use a compiler where there is an internal
data base of silicon issues is available to shape code generation
when processors are changed and code re-used.

Silicon I/O bugs are a lot more complex. Some of the bugs
must be dealt with at the library or driver level. A more complex
bug that we encounter in I/O is side effects based on order of
register access, for example buffers and flags are cleared based
on register access. A more complex case is the order requirements
to access 16 bit registers, both of these we code in our
compilers. These are the kind of issues that are encoded in
silicon revision to revision, for compiler writers it is often more
reliable to code around an issue and get it right once than repair
an inconvenient but not fatal silicon bug.

Walter Banks.

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist