[Mx-mailing-list] MX 1.2.0 is available

Bill Lavender lavender at agni.phys.iit.edu
Mon Mar 20 11:24:06 CST 2006


Versions 1.2.0 of MX, MP, and MxTcl are now available at the MX web site from
the download page

    http://mx.iit.edu/source.html

The primary feature of this release is the addition of support for running on
64-bit operating systems.  As part of this, old MX databases must be changed
to replace references to 'int' variables with references to 'bool' and 'long'
variables.  Read the changelogs below for more information.

Bill Lavender

**************** Changelog for MX version 1.2.0 ****************

Version 1.2.0 (03/17/06):
	The focus of this release has been the addition of support for 64-bit
	operating systems.  64-bit operation has been successfully tested
	on the following platforms:

	    alpha (Debian Linux 3.1, Tru64 Unix 5.1b, OpenVMS 8.2)
	    amd64 (Red Hat Enterprise Linux 3, SuSE Enterprise Server 9.0)
	    itanium (Debian Linux 3.1, Red Hat Enterprise Linux 4,
	    		FreeBSD 6.0, HP-UX 11, OpenVMS 8.2)
	    mips (Irix 6.5)
	    parisc (HP-UX 11)
	    sparc (Solaris 10)

	Interoperability between 64-bit and 32-bit clients and servers
	has also been successfully tested.  Please note that on platforms
	that support both 32-bit and 64-bit executables, you must uncomment
	the makefile macro USE_64_BITS in the appropriate Makehead.???
	file in order to compile a 64-bit binary.

	As part of this change, new MX data types have been added and
	some old data types have been removed.

	Data types added:
	    MXFT_BOOL   - Intended for boolean values (TRUE/FALSE).
	    MXFT_INT64
	    MXFT_UINT64

	Data types removed:
	    MXFT_INT
	    MXFT_UINT

	For network communication, the old data types should be changed
	to the new data types as follows:

	    MXFT_INT  ----+---->  MXFT_BOOL  (for TRUE/FALSE values)
	                  |
	                  +---->  MXFT_LONG  (for all other 32-bit values)

	    MXFT_UINT --------->  MXFT_ULONG

	Similarly, for MX database files, the following changes should
	be made:

	    int  --------+---->  bool
	                 |
	                 +---->  long

	    uint ------------->  ulong

	    net_int  ----+---->  net_bool
	                 |
	                 +---->  net_long

	    net_uint --------->  net_ulong

	For example, a database definition like this

id_ev_enabled variable net_variable net_int "" "" 10id id_ev_enabled.value 1 1 1

	would be changed to look like this

id_ev_enabled variable net_variable net_bool "" "" 10id id_ev_enabled.value 1 1 1

	By contrast, a database definition like this

id_ev_type variable inline int "" "" 1  1  3

	should be changed to look like this

id_ev_type variable inline long "" "" 1  1  3

	The general pattern is that you should replace TRUE/FALSE variables
	with 'bool' variables and everything else with 'long' variables.

	One of the rationales for removing the old 'int' data types is
	reduce ambiguity in the use of data types.  Traditionally, MX
	programs have treated 'int' and 'long' types as more or less
	equivalent.  On most 32-bit platforms, you can get away with
	this.  However, on many 64-bit platforms this is no longer the
	case and it was decided that the best way to reduce ambiguity
	was to eliminate the 'int' datatypes altogether.  For this
	release, MX assumes the following word sizes for integral data
	types:
	    char  - at least 8 bits long
	    short - at least 16 bits long
	    long  - at least 32 bits long
	    int64 - at least 64 bits long

	These definitions are compatible with the ANSI C standards up to
	and including C99.  Note that ANSI C actually only guarantees
	'int' to be at least 16 bits long.

	For network communications via either RAW or XDR mode, the integral
	data types are truncated to the minimum number of bytes shown above.
	However, for RAW connections between 64-bit MX clients and 64-bit MX
	servers that have the same byte order (big-endian vs. little-endian),
	it is possible to configure the MX network connection to transmit
	the full 64 bits of 64 bit longs by setting the 0x10000 flag in the
	'server_flags' field of the server record in the client's database.
	It might be possible to perform the same trick for XDR connections
	by bending the rules of XDR communication, but that has not been done
	for this release.

	Please note that by a careful choice of numerical datatype
	definitions, the modifications to MX network communication
	have been done in such a way that 32-bit and 64-bit MX 1.2.0
	clients and servers should be able to interoperate with old
	32-bit MX clients and servers that used the 'int' datatypes.
	This was mainly done by assigning MXFT_BOOL the same numerical
	value as the old MXFT_INT definition.

	New MX header files 'mx_stdint.h' and 'mx_inttypes.h' have been
	added to provide support for the new fixed length data types
	provided by the new C99 <stdint.h> and <inttypes.h> header files.
	The reason for providing my own header files is to make sure that
	the C99 definitions are available on MX build targets that do not
	already provide such definitions.  For example, on Linux the
	MX header files merely include the C99 header files, while for
	Microsoft Visual C++, the MX header files explicitly supply the
	missing definitions.  For now, "mx_stdint.h" is guaranteed to
	provide definitions for
	
	    int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t,
	    int64_t, uint64_t, intmax_t, and uintmax_t.

	The 'fast' and 'least' variants of these definitions are not 
	currently implemented.  The "mx_inttypes.h" header provides 
	definitions for the PRI series of printf() macros for 8, 16,
	32, and 64 bit integral types.  The SCN series of scanf()
	macros provides similar support for the 16, 32, and 64 bit
	integral types.  Unfortunately, it appears that it is not possible
	to provide support for the SCNd8, SCNu8, and SCNx8 macros on
	some platforms since the underlying vscanf() implementation
	only supports 8-bit types as ASCII characters rather as integers.

	Added a new header file 'mx_program_model.h' that specifies the
	integer programming model for the current platform.  The most common
	programming models are ILP32 (32-bit ints, longs, and pointers)
	supported by most 32-bit computers and LP64 (32-bit ints, 64-bit
	longs and pointers) supported by most 64-bit computers except for
	Microsoft's 64-bit versions of Windows.  The header file also
	defines a macro called MX_WORDSIZE for those cases where all
	you want to know is whether or not you are on a 32-bit or 64-bit
	computer.

	A new header file 'mx_xdr.h' has been added to manage the support
	of XDR data types by MX.  In addition, the files 'xdr_hyper.c'
	and 'xdr_hyper.h' have been added to the 'tools' directory to
	provide support for the 64-bit 'hyper' XDR data type on platforms
	that do not already provide such support directly.

	The old header file 'mx_types.h' has been removed since its
	functionality has been replaced by the new 'mx_stdint.h' 
	header file.

	The MX function API has been changed in a number of places to
	replace 'int' function arguments with either 'mx_bool_type'
	arguments or 'long' arguments.  This has required matching changes
	in the MP and MxTcl packages for Python and Tcl.  The general
	pattern has been to use 'mx_bool_type' for boolean values and
	'long' for everything else.  The reason for inventing a new
	type called 'mx_bool_type' rather than using the C99 'bool'
	or '_Bool' types is that as far as I know the C99 standard makes
	no promises as to how many bits there are in a 'bool' type, but
	I need a consistent definition of the number of bits in order
	to use them in network communication.  Thus, 'mx_bool_type'
	has been defined to use a 32-bit integer type.  If anyone can
	show me that the C99 standard _does_ guarantee that 'bool's are
	32-bits or more, then I will be happy to replace 'mx_bool_type'
	with the C99 'bool'.

	Please note that for this release, we use 'long' and 'unsigned long'
	for the data values provided by the digital I/O, stepper motor,
	pulse generator, scaler, MCA, and MCS device classes.  This means
	that you can only assume 32-bit precision in the values returned.
	Since I have not yet run into a piece of hardware that supports
	more than 32-bit values, I do not regard this as a significant
	limitation.  If such a piece of hardware does appear, I will
	reevaluate what to do then.

	A large number of trivial changes to print and scanf format strings
	have been made for the sake of 64-bit compatibility.

	If you have any questions about the changes for 64-bit compatibility,
	do not hesitate to contact me (William Lavender) about this.

	*******************************************************************

	In the meantime, a number of changes unrelated to the 64-bit
	transition have also occurred:

	The old, obsolete version of the "mxupdate" program that had
	been kept around for backward compatibility has now been deleted.

	Fixed an issue with "motor"'s "measure dark" command when used
	with the "epics_mcs" driver.  It turns out that sometimes the
	"measure dark" operation was using many more MCS measurements
	than had actually been requested by the user.  For example, if
	the user had just run a 3500 point MCS quick scan and then 
	requested "motor" to perform a single point dark current measurement,
	it turns out that "motor" was actually making a 3500 point dark
	current measurement and then throwing away all but the first 
	measurement.  Thus, the dark current measurement would take
	3500 times longer than the user had expected.  This issue was
	fixed by adding a call to mx_mcs_set_num_measurements() in the
	clear() function of the 'mcs_scaler' driver.  This location
	was chosen since it should have the least impact on the other
	current MCS drivers.

	Added code to the MX motor driver class and the "motor" program
	to distinguish between between tripping hardware limits and
	software limits in error reporting.  At present, the "epics_motor"
	driver is the only driver taking advantage of this feature.
	Usually, on an EPICS MEDM display, the distinction between the
	two will be that tripping a hardware limit will display a red
	error message which exceeding a software limit will display a
	yellow error message.  Support for this distinction will be 
	added as time permits to the drivers for motor controllers 
	that make this distinction themselves.  Many motor controllers
	only have support for hardware limits.

	A variety of drivers have been updated to use the snprintf(), 
	strlcpy(), and strlcat() functions instead of the older sprintf(),
	strcpy(), strcat(), strncpy(), and strncat() functions.  This is
	because the new functions do a better job of protecting against
	buffer overruns.  snprintf() is widely available on most MX build
	targest, but has been redefined as sprintf() on the small number
	of MX build targets that do not support it.  strlcpy() and strlcat()
	are less well know.  They are versions of the string functions for
	which you always provide the full length of the buffer you are
	copying to rather than expecting the programmer to provide a
	potentially faulty calculation of the unused length left in the
	buffer.  Since most platforms do not currently support strlcpy()
	and strlcat(), versions derived from OpenBSD have been bundled
	with MX in the 'tools' directory.

	Added support for HP's Tru64 Unix operating system on 64-bit Alpha
	based computers.

	Updated support for the HP-UX operating system to HP-UX 11.

	Added preliminary support for the eCos real time operating system.
	This support has not yet been fully tested.

	Support for the Intel compiler on Linux has been updated to Intel
	C 9.0.

	Increased the buffer size for 'set_position' commands in the
	'compumotor' driver.  This was in response to reports of buffer
	overruns at CAMD.  As it happens, the 'compumotor' driver is one
	of the drivers that has been updated to use the snprintf(),
	strlcpy(), and strlcat() functions, so this driver should be
	relatively immune to buffer overruns in the future.

	The Makefile for OpenVMS only works with some ports of Gnu make
	and not others.  Some explanatory text has been added to that
	makefile to indicate which version of Gnu make should be used.

	The 'smartmotor_aout' driver was actually reading from the output
	pin rather than writing to it.  This has been fixed.

	Fixed a bug in the 'mc6821' digital I/O interface driver.  Until
	now, the data direction for port B had incorrectly been set to the
	data direction requested for port A.

**************** Changelog for MP version 1.2.0 ****************

Version 1.2.0 (03/17/06):
	Minor tweaks to accomodate changes in the MX API for MX 1.2.0.

**************** Changelog for MxTcl version 1.2.0 ****************

Version 1.2.0 (03/17/06):
	Minor tweaks to accomodate changes in the MX API for MX 1.2.0.




More information about the Mx-mailing-list mailing list