Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Good point Mike. One of the first things I did when I started my Polaroid contract a year or so ago was to build on my Alpha, which is 64 bit little endian. In the office they were using both Debian and Solaris on Intel hardware with the final target being Solaris/Sparc. The portion of the product that I worked on was a btree database. One problems I ran into on the Sparc was not an endian problem, but a data alignment problem. On most RISC chips, data must be aligned on its natural boundary. A 64 bit integer must be aligned on an 8 byte boundary, 32 bits on a 4 bytes, etc. On the Alpha, the kernel was set to fixup alignment traps, but Solaris on the Sparc was not. The key data was set up in an array of key/offset pairs. If the key length was not a multiple of sizeof(long), accessing the offsets would result in a trap. I did not have time to restructure the key algorithms, so I had to revert to using memcpy instead. Mike Bilow wrote: > The tools work, but watch out for subtle machine dependencies. Solaris is > BSD-ish while AI/X is POSIX-ish. Solaris usually runs on bigendian > machines, while AI/X commonly runs on biendian machines. Native word size > also varies with platform, with AI/X sometimes on 32 or 64 bits, and > occasionally on weirdo mainframe-legacy things like 24 or 48 bits. -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |