Bus Errors & Power PC

1. 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)

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

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 [de]allocates 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