Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news99.sunet.se!nntp-trd.UNINETT.no!nntp.uio.no!NewsWatcher!user From: Kolbjorn.Aambo@ub.uio.no (Kolbjørn Aambø) Newsgroups: comp.lang.beta Subject: Re: The signes, sizes and Endianness of Basic pattern Date: 5 Jan 1996 09:28:12 GMT Organization: University of Oslo Libray Lines: 167 Message-ID: References: <4cevvf$5ti@krone.daimi.aau.dk> NNTP-Posting-Host: ubmac86.uio.no In article <4cevvf$5ti@krone.daimi.aau.dk>, olm@daimi.aau.dk (Ole Lehrmann Madsen) wrote: .. .. About endianness, I would like to know more about how you think .. of using your proposal. Do you need to operate on little endian .. integers on a big endian machine, or do you just need to be able .. to exchange objects between little- and big-endian machines? If data is written on a little-endian shared device by a Litte- endian Machine I want to be able to read and update it using a big-endian Machine. This entails beeing able to convert them to big-endian format when processing read information and converting them back to little-endian when writing to the Little-endian shared device. An implication of this is that yes I need to be able to operate on little-endian Integers etc on a big-endian Machine AND operate on big- endian Integer etc on little-endian machines. So what we need here is little and big-endian basic patterns in any Compiler that also implicitely translate between the basic pattern types where that is needed and is of course best detected by the compiler! This will give BETA and additional advatage when it come to deal with PCI devices on an Big-endian Machine since all PCI devices are Little- endian! An other example is Opendoc where a lot of internal structures are stored in little-endian whether the machine it's running on is little or big-endian! So I guess we have the choice between doing al this conversion over again for evry single program, or letting the compiler do it that realy can tell the difference if only basic-pattern can be typed explicitely when it comes to endianness. When you are now working on a PowerPC implementation it can be done rather efficiently since it can switched between big and little-endian. For Pentium and 68K I'm not shure if it will be that efficient but still it will bee a boone for the programmer that dont have to deal with this problems explicitely. .. .. The Mjolner Beta System currently has support for persistent objects. .. One of the strengths of the Mjolner Beta system (as wee see it) .. is that it has good support for multi-platform support. .. The new GUI-library is e.g. platform independent in the sense that .. the code can be easily ported (just a recompilation is needed) .. between Unix/Motif, Windows 95/NT and Macintosh. My impression is that your persistent store is a research project and not a real database product. I would probably like to store objects in a more Normalised -relational i.e. without duplicated information kind of way.... .. .. We are working on being able to exchange persistent objects between .. little- and big-endian machines. The objects format is the same .. for alle machines, except for the endian problem. The compiler .. generates the necessary information to be used by the persistence library .. to be able to convert between little and big endian machines. .. It just need to be used by the persistence library. Then you have already solved a lot of the problem, what remains is to introduce some additional basic pattern to the language. I understand well that this can not be done over night, but it's nice to know that this can be awailable, in a year? ;-) .. So my question is: do you need more than being able to exchange .. persistent objects between litte- and big-endian machines? YES! .. .. To further improve support for multi-platform, we are currently working .. on making the distribution library work in a heterogeneous environment .. of Unix, Windows 95/Nt and Macintosh computers (i.e. machines .. with different endians) .. .. Finally, you also mention that you would like support for Unicode .. text. This is of course also something we have on the list. .. So far it has not been given any high priority, since nobody before .. you have asked for it. Could you tell us something about the .. Unicode based tools you are using! I assume that you are using .. some editors, etc. that can produce Unicode documents? .. In general we are interesting in knowing how much Unicode is .. used in practice. .. .. Thanks. .. You probably allready know that Windows NT is Unicode based, and that MacOS 8 will be Unicode based. Additionally Java have Unicode, Newton is Unicode based, Http will be. No, I dont have any applications doing Unicode because I want proper tools, that means waiting for MacOS 8. If you can get me Unicode in BETA any erlier than MacOS 8 I will start using it for backing up digital objects in the library in Unicode instead of in several other character sets, since Unicode or properly ISO/IEC 10 646 is the only usful future for multilingual information that we have a lot of in our library. By the way I have been working in the Comitee for a few years to ensure that the Danish/Norwegian/Latin letter Æ (Letter AE) is to be seen as a LETTER and not as a mere Ligature between A and E. During that process I have been able to smell that the entire industry of Machine manufacturers are going towards Unicode. To have a real language gives the programmers a real excuse to use it. After been looking at C++ for a few years I'm convinced tha using that lanuage is a vaste of human life-time and have made me seriously conidering returning to BETA if it can be given a full implementation on at least Macintosh, Windows Windows NT and probably a heavy Iron server where I would prefere DEC Alpha but would be able to live with the SUN-Sparc you already have been working on. I would realy hope that you get energy and money to stay close to your compiler and develop it toward a comercial and (cost) efficient product! From earlier postings I have got the impression that speed of programs in BETA can be compared to unoptimalized C/C++ wich is not too bad when comparing to a lot of other Garbage Collected systems. I reagard optimalized systems secondary to the things mentioned above. I also think that optimalisarion will be another thing a couple of years from now when Chaching and CISC vd RISC is better understood, even by the Manufactorers or at least their sales people....;-) I have regarded the folowing basic pattern as interesting: 0 Boolean (Should only be represented Bi-Endian) 1 Unsigned Octet (8-bit byte, Bi-Endian) 2 Signed Octet (8-bit byte, Bi-Endian) 3 Unsigned BigEndian Integer16 4 Unsigned LittleEndian Integer16 5 Signed BigEndian Integer16 6 Signed LittleEndian Integer16 7 BigEndian Unicode 8 LittleEndian Unicode 9 Unsigned BigEndian Integer32 10 Unsigned LittleEndian Integer32 11 Signed BigEndian Integer32 12 Signed LittleEndian Integer32 13 Unsigned BigEndian Integer64 14 Unsigned LittleEndian Integer64 15 Signed BigEndian Integer64 16 Signed LittleEndian Integer64 17 BigEndian Float64 18 LittleEndian Float64 19 Unsigned BigEndian Octet String (Zero terminated) 20 Signed BigEndian Octet String (Zero terminated 21 Unsigned LittleEndian Octet String (Zero terminated) 22 Signed LittleEndian Octet String (Zero terminated 23 BigEndian Unicode Text (implicit length in Unsigned BigEndian Integer32) 24 LittleEndian Unicode Text (implicit length in Unsigned LittleEndian Integer32) What do you think? I'm been working on a format for storing information in a file that have coding for whether the cells in it are big or little endian and whether the cells are 32 or 64 bits. I have made such an effort to suggest a flat file format where the cells are no longer 8 bit bytes because that don't apply to unicode encoded texts and/or other "binary" data. -- Kolbj|rn H. Aamb|, University of Oslo library/Bibliographic dept. N-0242 Oslo, Norway kolbjorn.aambo@ub.uio.no Phone: +47 22 85 91 36 ................................................................ They brought their books, the natives had their land, then... they got their land, the natives only books.