Bus Errors

1
Bus Errors Power PC

• VME Bus Error can generate a Machine Check
  Exception (MCE)
• The WRS mv2700 BSP doesnt have code to do this
• Write cycles complete normally, Read cycles
  return 0xffffffff
• I can provide code to generate a MCE on VME Bus
  Error
• For read cycles on an mv2700, the MCE appears to
  be synchronous
• The instruction that caused the MCE is given
  (although vxWorks exception report doesnt say
  what address was being accessed)
• Write cycles can be delayed well beyond the end
  of their instruction
• The Universe-2 VMEbus interface chip contains a
  Write Posting FIFO
• Write Posting is usually enabled for the A32
  window, but not the A16
• MCE is not asserted if a write-posted cycle gets
  a Bus Error
• It can generate an interrupt instead, and the
  BERR address is saved
• For a coupled write cycle, the MCE is
  asynchronous and may indicate a different routine
  (a task switch seems unlikely, too many
  instructions)

2
C Guidelines for Base

• Andrew Johnson
• APS/ANL

3
C in R3.14 Alpha-1

• 3.14 is the first version of Base with C code
  in the IOC
• Tornado 2.0 first version of vxWorks to support
  this
• Solaris, Win32, Linux and RTEMS also support C
• Why use C?
• Increased type safety
• Structural advantages modularity, inheritance,
  templates
• Future needs of EPICS community
• No C compiler is fully ISO C compliant yet
• Different C features are missing on different
  compilers
• The C Standard Library is not uniformly
  implemented or efficient on different platforms

4
C in Base

• 3.14 Alpha-1 has the following C components
• Portable CA server (not used in the IOC yet)
• Channel Access client library
• Some C facilities in libCom used in the above
• Dont rely on the libCom C facilities in 3.14
  Alpha-1!
• The APIs and functionality will be changing
• 3.14 libCom C facilities are being revised to
  provide
• A subset of ISO Standard C APIs where practical
• string, linked list, hash table
• Simple class interfaces to common facilities
  independent of OS
• binary mutex semaphores, threads, timestamp,
  timers, ring buffer

5
C Features to Beware

• Exceptions are not fully supported on all
  platforms
• Exception-safe library code is hard to write
  correctly
• Base will provide macros to allow
  platform-independent code, calling cantProceed()
  where throw() is not available
• Namespaces are not supported on all platforms
• Where they are, C facilities in libCom will
  appear inside a namespace epics block.
• Base will provide macros to allow
  platform-independent code
• Explicit template instantiation can vary slightly
  between the different compilers
• The more advanced template features are commonly
  unavailable on one or more compilers

6
The C Standard Library

• We want to use standard C APIs where we can,
  but
• The implementation of the standard containers
  (list etc.) is very slow on certain platforms
• Tornado 2.0 versions are particularly bad, list
  is up to 12 times as slow as the equivalent
  ellList library in C
• Where these are most useful Base will provide an
  efficient version that supports a subset of the
  standard API
• Standard library containers could fragment the
  free memory pool over a long period of time
• Every list insert and delete operation
  deallocates memory
• Base implementations of standard containers use
  free-lists
• Base provides a free-list template for other
  classes to use

7
Further C Reading

• IOC Application Developers Guide for R3.14
• Will describes the C facilities in libCom when
  finalized
• More Effective C by Scott Meyers, Addison
  Wesley
• These 2 books are now available in HTML on one
  CD-ROM with a search engine, extensive
  cross-links and some extra material
• The GNU C compiler in Tornado 2 has a Weffc
  switch that warns about code that violates some
  of Meyers guidelines
• Mozilla has even bigger portability problems than
  EPICS, and provides guidelines for developers at
• http//www.mozilla.org/hacking/portable-cpp.html