# Presentation: 479150

## Bus Errors & Power PC

- VME Bus Error can generate a Machine Check Exception (MCE)
- The WRS mv2700 BSP doesn’t 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 doesn’t 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)

## C++ Guidelines for Base

- Andrew Johnson
- APS/ANL

## 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

**Notes:**
Modularity: encapsulation, information hiding

## 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
- Don’t 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

## 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

**Notes:**
Exception-safe: works properly in the presence of exceptions
Exception-neutral: propagates all exceptions correctly to the caller

## 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 [de]allocates memory
- Base implementations of standard containers use free-lists
- Base provides a free-list template for other classes to use

## 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](http://www.mozilla.org/hacking/portable-cpp.html)_