Back Midas Rome Roody Rootana
  Midas DAQ System  Not logged in ELOG logo
Entry  22 Jan 2007, Carl Metelko, Forum, Midas on a x86_64 
    Reply  22 Jan 2007, Konstantin Olchanski, Forum, Midas on a x86_64 
       Reply  12 Jul 2007, Konstantin Olchanski, Forum, Midas on a x86_64 - incompatible with x86_32 
          Reply  13 Jul 2007, Stefan Ritt, Forum, Midas on a x86_64 - incompatible with x86_32 
             Reply  12 Aug 2007, Konstantin Olchanski, Forum, Midas on a x86_64 - incompatible with x86_32 
                Reply  20 Aug 2007, Konstantin Olchanski, Forum, Midas on a x86_64 - incompatible with x86_32 
                   Reply  29 Aug 2007, Konstantin Olchanski, Forum, ODBv3, second try - Midas on a x86_64 - incompatible with x86_32 
                      Reply  21 Nov 2007, Konstantin Olchanski, Forum, ODBv3, second try - Midas on a x86_64 - incompatible with x86_32 
    Reply  26 Jan 2007, Carl Metelko, Forum, Midas on a x86_64 
Message ID: 396     Entry time: 13 Jul 2007     In reply to: 395     Reply to this: 399
Author: Stefan Ritt 
Topic: Forum 
Subject: Midas on a x86_64 - incompatible with x86_32 
> The biggest problem here is that making 32-bit ODB and 64-bit ODB compatible requires breaking one or
> the other (My proposed changes break the 64-bit version. Alternatively, one could add explicit padding
> to these data structures and break the 32-bit ODB).
> 
> I think it is important to make 32-bit and 64-bit code compatible: at TRIUMF we have to use a mixed
> environment because out latest host computers all run 64-bit Linux while all our VME processors and all
> older machines can only run 32-bit code; this incompatibility causes us weekly headaches.
> 
> Any thoughts?

I agree to make 32-bit and 64-bit compatible. In the long run, everything will be 64-bit, so I would suggest
in breaking the 32-bit ODB, add some padding there where needed, probably with some conditional compiling.
This ensures to keep the native 64-bit packing, which probably will be somehow optimized for 64-bit
architectures and therefore might be a bit faster in the long run, when most systems are 64-bit. After this
has been implemented and well tested, I would go with an official announcement of the 32-bit break in the ODB,
and release a new version, so people can update from a TAR file if necessary. Existing ODB's can be converted
to the new format by exporting them in XML form and importing them again after the upgrade.
ELOG V3.1.4-2e1708b5