Description of Data Formats on new (VME PowerPC) Frig Front Ends
			  Dennis J. Nicklaus
			      July 1999

I encountered a large problem when porting the Frig front end code
from the 386 to the Power PC.  The PPC is different endian machine
than the 386.

If everything were done nicely, this would be a problem because we
could just adjust the Database primary transforms for all the Frig
devices, and that would solve the problem.  However, that doesn't 
really work in this case.  Numerous reasons why are listed below.

The solution arrived at is that, on the PPC Frig front end,
	ALL THE FRIG DEVICES ON THE FRIG FRONT ENDS
	RETURN 386-ENDIAN ORDERED DATA.  

All the primary transforms in the database remain unchanged so that
VAX still expects the data in the same endian order as before (386
endian, which is the same as VAX endian).  All this is true even
though the PPC is opposite-endian than the 386 and VAX.

This means that in the PPC front end, all the values Set and values
returned back from a Read, and, generally, values stored locally on the
front end (e.g. alarm block limits, etc.) will all be in non PPC-endian
format, and they must be end-swapped before they can be used.
On the PPC, the end-swapping that must be done is to switch a 4byte word like
		0x12345678
into		0x56781234.
Before the front end code uses any values in computations such
as alarms limits checking, in running Frig loops, FSMs, etc., it must
be end-swapped before it is used. Extra special care must be taken with
floating point numbers so that we don't use a non-PPC endian value as a
floating point number and cause some floating point exception. 



Where are some of the reasons why just changing the Database primary
transforms doesn't work:
#1: Some (probably most) Frig console applications
	(F21 is the one I have started with) totally ignore transforms
        and get their data through dio_get_raw calls instead of dio_scaled...
#2: For a lot of the data read back by the frig applications
	(but not all  of it), the data is a big structure of a mix of
	types (float, short, int) that the primary xforms can't handle anyway.
	However: F21, at least, (and I imagine all the other apps) retrieve
	their data with calls like dio_get_lst_raw_c which bunch up the
	simple data types (i.e. one floating point number) with the
	more complicated types so that even these simple ones which 
	potentially could be "nicely" transformed aren't.

#3: During the changeover phase of the project these console applications
	must work with both the old (386) frig'es and the new ones.

For a little more background in this, you have to know that ALARMS limits
testing is done on the front end.  So for the FE to do this properly,
it must have read-out values and limits in proper floating point format
(or integer as the case may be) for the FE processor. The limits are
sent through the reverse primary xform for downloading to the FE
for processing, and the current value read by the FE should generally
be in the correct FE format also.


I do not like having these end-swaps in the front end code, and wish
that the console applications were written differently so that it
could all be done through the database transforms, but that isn't
the way it worked out.