Hi Flemming, Steve, et al, On Sat, 3 Nov 2001 17:02:22 -0500 "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning "Re: ppc db access": > Dear Steve, > > When we talked about this today I thought there was a byte issue, > but let us look at the facts. The content tables usual of the > calibration tables are stored as the 'hex' number in ascii formed > and unpack /packed as such from mem to from ascii string. (byte > oriented reading/writting). See the methods BrDb::Addr2String, BrDb::String2Int, and so on [1]. What actually happens is this: Each byte in at the address pointed to by the argument addr is split into 2 bytes: one byte encoding the upper 4 bits, and one encoding the lower 4 bits. This means that the final size of the BLOB is 2*size+1 - the final one is for the string terminator '\0'. > Since the DB is stored by taking the incrementing 'byte' converting > to ascii hex and storeing in the DB, I do believe that the order > becomes reversed when reading to another machine. Thus to work with > the ppc (and not the fix any existing DB) I think one has to add > aprropriate compile flags + code in the routines String2Float > ,.. for the reading , and if you want to write from the ppc, it > seems from my reading of the code we have to expand the content of > the single Address2String that is used for storing, since one really > has to know the type (or at least size) of individual elements. When Anders and I was at BNL last spring I believe we - that is Flemming, Anders, Konstantin, and I - discussed this issue of byteswapping, and I believe we came to the conclussion, that the way I finally implemented the encoding was indeed free of byte-swapping issues. > Christian, would you please go over these arguments and propose a > solution. Well, if there is a problem, which I don't believe there to be, the appropiate thing to do is to keep the writting and reading in one particular ordering - which would mean that we'd have to insert ordering specific code into the methods BrDb::Addr2String, BrDb::String2Int, etc. The information on the type is already avaliable in the BrDbParameter class, so, there's no need to change a lot in the interface. > I think it is a matter of byte-swapping only at least between linux > i286 and linus ppc which uses IEEE floating and double (?). ^^^^^^^^^^^^^^ |||||||||||||| You do mean 'i386' and 'Linux' don't you? I don't think ANYONE is working on a 80286 anymore, and Linux will certainly not run on such a machine - no 'protected mode' on the chip. To those of you that think I'm a young lad that do not know the glorious days of VAX, IBM 80286, Amiga, PDP-11/45, etc. - well, I did write a rather long assignment on a 80286 Portable (if you had a car that is) for secondary school. Yeaks, I still get horrible flashbacks of the brown/yellow screen - even though my first two years of working with Linux was on a VT100 terminal (a 386 with 4MB ram does not go well with X). To answer your question mark: If there's a problem with byteswapping, it's a problem for all big/little endian machines, not just the Apple chip. I'm not sure, but I think a Sparc has a different endian-ness than the i386, so we could probably test my claim that there's no problem from the rmine machines. Ok, I just checked on rmine001 using the small program: #include <RConfig.h> #include <iostream.h> int main (int argc, char** argv) { cout << "R__BYTESWAP " #ifdef R__BYTESWAP << "is" #else << "isn't" #endif << " defined" << endl; return 0; } which on gives Machine Output rcas0009 R__BYTESWAP is defined rmine001 R__BYTESWAP isn't defined so the Sparc defently has different endianness than the i386. So what I'm doing right now, is to compile BRAT on Solaris, and then I'll try to access the data from the database from rmine001. I'll let you know the outcome. > ----- Original Message ----- > From: "Stephen J. Sanders" <ssanders@ku.edu> > To: <brahms-dev-l@bnl.gov> > Sent: Saturday, November 03, 2001 9:40 AM > Subject: ppc db access > > > > Hi, > > As evidenced by a number of recent messages to this group ^^^^^ ||||| Someone has a past on Usenet! > > I am trying to access the mysql db from the linuxppc system. With > > Djamel's and Christian's help, I think I now have this done. Good - it's rather simple isn't it? > > However, I now encounter what may be a serious problem: > > All of the numerical values that I'm getting back are garbage. > > The ascii type information seen to be OK (at least, the strings > > output when I issue the Print method from BrCalibration seem OK), > > but the numbers are nonsense. Ok, I think you have to be a bit more specific than that: When Br<...>Calibration returns numbers it looks odd or what? And when you print the same numbers via BrValibration::Print they look ok? If the output of Print looks fine, then there's no problem in the database classes, and it's a case of EBID (ask the norwegians what that means). One think I could imagine that could also potentially cause problems: I bleieve the Aplle chip is 64bit, while the i386 is 32bit. That means that the size of int on Apple is 8bytes, while on i386 it's 4bytes. Now, if you use the native int's, then you may see this problem. However, if you use the ROOT Int_t you should not see any problem, since the ROOT Int_t is _always_ 4bytes long. I think I've said this a couple of times, and it's defently in "The Guide": Use the ROOT machine independent types Int_t, UInt_t, Short_t, UShort_t, Long_t, ULong_t, Float_t, Double_t, Char_t, UChar_t, and so on! One of the points of using ROOT is exactlyu that it provides machine independent abstraction layers (those of you that read roottalk may remember a recent discussion on GUI's - not how you change every third tick on an axis to be blue!). > > Does anyone know if there is a byte-swapping issue with db access? As I said, I don't believe there is, since we actually spend quite a lot of time thinking about this - the fine minds of Flemming, Anders and Konstantin were all there - when we designed the ting last spring. Konstantin, if you're reading this, can you perhaps give a short comment? Thanks. [1] http://pii3.brahms.bnl.gov/~brahmlib/brat/VER-2-0-31/html/BrDb.html Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Sun Nov 04 2001 - 10:39:17 EST