Date: Fri, 16 Feb 2001 01:10:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter.jeremy@alcatel.com.au (Peter Jeremy) Cc: tlambert@primenet.com (Terry Lambert), Peter.Blok@inter.NL.net, freebsd-alpha@FreeBSD.ORG Subject: Re: unaligned access Message-ID: <200102160111.SAA12619@usr08.primenet.com> In-Reply-To: <20010216114244.G90937@gsmx07.alcatel.com.au> from "Peter Jeremy" at Feb 16, 2001 11:42:44 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> >But remember that your problem is not the fixups themselves, > >but that the code does not operate in the presence of fixups, > >which it should. > > That assumes that the code is not time critical and is not trying to > perform atomic operations on non-aligned objects. Each fixup implies > a trap to kernel mode and then emulating the instruction - this is at > least 2 orders of magnitude slower than if the reference was aligned. > If unaligned accesses are printed, that probably adds another couple > more orders of magnitude slowdown (even graphical console I/O is > glacial compared to instruction issue rates). I've run PPP on a 7.14 MHz Amiga, so I'm going to guess that time criticality is not wht's breaking you. 8-). > Atomic accesses are inherently incompatible with non-aligned objects. Yes; but as PPP is a stream protocol, I'm also going to guess that it's no unlocked access that's shooting you. 8-). -- Both of the above said, I think that unaligned accesses in the code need to be fixed, if only so that the code is a godd example of correct architecture independent coding. But even if it weren't, and you rely on the fixup handler, the code _should_ be able to run correctly, if slowly. > I didn't keep the head of the this thread, but I've also found that > "all the world's a VAX" (or at least an i386) is still alive and > healthy in the freeware world. There's a _lot_ of code that assumes > that ints, longs and pointers are all 32 bits and you can safely > store a pointer in an int. Most of these assumptions are likely to > lead to segmentation violations. Compiling your code with lots of > warnings enabled can be very enlightening. Well, the alpha byte order makes that a correct assumption for originally x86 code running on an Alpha. I agree that byte order assumptions could make the code non-portable to other architectures (SPARC, 68k, MIPS, PPC [latter two, if processor is set to use that order]). As for object size, that could be your problem, too. I _know_ that packing could be an issue, since it was for me on some code (I didn't write it!) which I had to port to an Alpha, but it could be that object size is biting you. I think that we've so far punteded on dealing with the old sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long). That should leave only packing. There's a nice tricky array packing issue as well, which I've never been able to get a satisfactory answer as to what is done with it with "#pragma pack(1)", which I think only affects structure packing, and not array boundary packing. You can see this by: struct foo *foop; foop = NULL; printf( "a foo is this big: %d\n", sizeof(*foop)); printf( "a foo slot is this big: %d\n", &foop[1] - &foop[0]); MIPS was famous for packing these non-adjacently, and starting foop[1] on the next alignment boundary. I suspect that your PPP code doesn't have this, unless it's using a structure index of a header structure and doing an array reference instead of a sizeof() addition to the original char pointer, in order to get the next thing in the buffer, and cast it to the next type. The only thing I have left to say on this subject is that it you get to the point where you have data and a serial dump, and need help reconciling it, I can help put you into contact with the author of the mpd code; realize that it was developed on x86, so be sure you deal with the architectural issues before you ask for his help. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102160111.SAA12619>