Double Initialization Values 
Author Message
 Double Initialization Values

We have a 64 bit interface to our Flash memory.  Flash commands are
represented as double data types. The command data must be exact 64 bit
patterns. Is there a way to guarantee the bit pattern when initializing
double data? My solution was to create an array of 32 bit constants, two
entries per Flash 64 bit command, and then access two entries with a
pointer to type double. This works just fine but it seems like there
should be an easier way. Any type casting that I tried seemed to alter
the bit patterns. Using defines also altered the bit patterns.
Thanks

--
***************************************************************************

*  Brian Aingworth                   Phone : (607) 751-2071
*  Lockheed Martin Federal Systems   FAX   : (607) 751-2397
*  Owego,NY                          E-mail:

*
*                Only my own opinions are offered.
* To reply remove the string "#NOSPAM#"
***************************************************************************



Mon, 02 Apr 2001 03:00:00 GMT  
 Double Initialization Values
You can try a union of a double and whatever integral types you need. It's
essentially the same method you have now, but a little tidier [code below is
not tested]. /Russell

typedef union
{
    double d;
    unsigned long aul[2];

Quote:
} Flash;

...
    Flash f;

    /* Initialize bit patterns */
    f.aul[0] = 0xFE56A001;
    f.aul[1] = 0x01A95FFE;

    /* Send as double */
    Interface(f.d);
...

Brian Aingworth wrote ...

Quote:
>We have a 64 bit interface to our Flash memory.  Flash commands are
>represented as double data types. ...



Mon, 02 Apr 2001 03:00:00 GMT  
 Double Initialization Values

Quote:

> struct mystruct
>   int       i : 2;
>   unsigned  j : 5;
>   int         : 4;
>   int       k : 1;
>   unsigned  m : 4;

> ) a, b, c;

> This corresponds to the following bit pattern:

> Hi                        Lo
> 0000   0   0000   00000   00
> m      k   not    j       i
>            used

Or this one:

    Lo                        Hi
    0000   0   0000   00000   00
    m      k   not    j       i
               used

It's not portable to rely on the layout of bitfields in a struct, just as
it's not portable to rely on padding (or the lack thereof).

If you need portable access to the bits in an integral value, use bitwise
operators on unsigned values.

--



Mon, 02 Apr 2001 03:00:00 GMT  
 Double Initialization Values
Have you thought of using bitfields? I covered them briefly in an
article about bitwise operators. (article #

still be around under the title "Good text for info on bitwise
operators")

Basically, they let you use an int value as a struct. For example:

struct mystruct
  int       i : 2;
  unsigned  j : 5;
  int         : 4;
  int       k : 1;
  unsigned  m : 4;

) a, b, c;

This corresponds to the following bit pattern:

Hi                        Lo
0000   0   0000   00000   00
m      k   not    j       i
           used

You can access i, j, k & m as normal struct members, eg a.m. Depending
on what compiler you use the actual width of the bit field struct may
vary. You might have them as 32 bits long, or 16, or something else
(obviously you will need to find out). However, once you do find out, it
should be fairly easy to use a number of them to convert them into a 64
bit data type:

unsigned double i;

/*assuming a 16 bit bitfield struct, j, k l & m have already been
initialized as these structs*/

i = (j * pow(2.0, 49.0) + (k *  pow (2.0, 33.0)) + (l * pow(2.0, 17.0) +
m;

I'm sure other members of this group will be able to suggest work
arounds or alternatives if I'm completely wrong.

Quote:

> We have a 64 bit interface to our Flash memory.  Flash commands are
> represented as double data types. The command data must be exact 64 bit
> patterns. Is there a way to guarantee the bit pattern when initializing
> double data? My solution was to create an array of 32 bit constants, two
> entries per Flash 64 bit command, and then access two entries with a
> pointer to type double. This works just fine but it seems like there
> should be an easier way. Any type casting that I tried seemed to alter
> the bit patterns. Using defines also altered the bit patterns.
> Thanks

> --
> ***************************************************************************

> *  Brian Aingworth                   Phone : (607) 751-2071
> *  Lockheed Martin Federal Systems   FAX   : (607) 751-2397
> *  Owego,NY                          E-mail:

> *
> *                Only my own opinions are offered.
> * To reply remove the string "#NOSPAM#"
> ***************************************************************************

--
Marcus Houlden  marcus_houlden (at) hotmail (dot) com
http://members.xoom.com/mhoulden  Remove all the JUNK to reply
PGP Key ID: 0x11C532FF
Please reply to my Usenet posts by Usenet, not email.


Tue, 03 Apr 2001 03:00:00 GMT  
 Double Initialization Values


Quote:
>We have a 64 bit interface to our Flash memory.  Flash commands are
>represented as double data types.

Why? double seems to be entirely inappropriate for this. What double
related operations can you make use of?

Quote:
>The command data must be exact 64 bit
>patterns. Is there a way to guarantee the bit pattern when initializing
>double data?

The only sure way of specifying bit patterns is to use an array of unsigned
char. If you define something like

typedef struct {
    unsigned char[8];

Quote:
} flashdata_t;

Then assuming you have 8 bit bytes and no strange struct padding here
(which is unlikely) then you can perform operations such as assignment
on flashdata_t objects as a single unit. You can access the data within
such a unit by accessing the individual characters of the array.

Quote:
>My solution was to create an array of 32 bit constants, two
>entries per Flash 64 bit command, and then access two entries with a
>pointer to type double. This works just fine but it seems like there
>should be an easier way. Any type casting that I tried seemed to alter
>the bit patterns. Using defines also altered the bit patterns.

As far as C is concerned you're generating indeterminate double values
so accessing those values results in undefined behaviour, e.g. loading such
a value into a floating point register might generate some sort of trap.

--
-----------------------------------------


-----------------------------------------



Tue, 03 Apr 2001 03:00:00 GMT  
 Double Initialization Values

Quote:

>We have a 64 bit interface to our Flash memory.  Flash commands are
>represented as double data types. The command data must be exact 64 bit
>patterns. ...



This is almost certainly a bad idea; read on.


Quote:

>Why? double seems to be entirely inappropriate for this. What double
>related operations can you make use of?

It is a bit hard to tell from the original phrasing, but chances
are that Mr. Aingworth means that the I/O device that contains the
Flash RAM requires 64-bit-at-a-time transactions for at least some
of its operation.

Of course, this particular requirement immediately leaves portable
C in the dust.  C makes few guarantees about sizes of objects, and
no guarantees whatsoever about underlying bus transaction sizes.

Nonetheless, if your CPU "just happens" to have a 64-or-more-bit
data bus, your C system *probably* uses 64-bit data transactions
when operating on 64-bit-wide data types that are aligned on 64-bit
data boundaries.  If the only 64-bit-wide data type your C system
provides is "double", you may be stuck trying to use "double"s to
implement 64-bit integral bit patterns.

How well this works, if it even works at all, is again up to the
implementation.  Some CPUs *will* do "double" accesses 64 bits at a
time, but will only do it through floating-point registers, and
will "normalize" all bit patterns moved through such registers, or
produce "reserved operand" faults on some bit patterns, or something
similar.  Others will pass any bit pattern through unchanged;
there, the union trick others have suggested will probably do the
job.

Another, and I think more interesting in general -- and actually more
relevant to comp.lang.c -- method is to do as Lawrence Kirby suggests
(with a minor correction here):

Quote:
>... If you define something like

>typedef struct {
>    unsigned char data[8];
>} flashdata_t;

>Then assuming you have 8 bit bytes and no strange struct padding here
>(which is unlikely) then you can perform operations such as assignment
>on flashdata_t objects as a single unit. You can access the data within
>such a unit by accessing the individual characters of the array.

Most compilers will not copy these structure objects using a 64-bit
access, but most compilers *will* allow you to write assembly stubs,
where you can use appropriate machine-dependent code to implement
"send flashdata_t to card" operations.  These stubs are of course
entirely non-portable, but the rest of the code can then be portable.

Note that if you use bitfields, you not only run afoul of the same
problem that you get with the struct-containing-array above -- that
the compiler is unlikely to use the proper specific-width operations
-- but you also run into compiler-dependent bit layouts.  This means
you are better off using arrays of unsigned integral types (char,
short, int, or long) and manual bit masks, when talking to external
hardware.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc

Antispam notice: unsolicited commercial email will be handled at my
consulting rate; pyramid-scheme mail will be forwarded to the FTC.



Tue, 03 Apr 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. addition long values to long double value ?

2. __int64 negative value initialization bug in VC6 (SP5), may be VC7 also

3. Sorting on double values.

4. question about huge double value

5. Largest double value ...

6. Convert a string to a double value ?

7. value of : (double) clock( ) / CLOCKS_PER_SEC

8. double not assigning value

9. Inconsistent intemediate values in double (egcs bug?)

10. Double random value

11. sum of double values not the same after re-fetch from dbase

12. defaultvalue error while setting to a double value

 

 
Powered by phpBB® Forum Software