From -291609286781206759 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,10e355266b6fd117 X-Google-Attributes: gidfc772,public X-Google-Thread: f78e5,10e355266b6fd117 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-05-30 09:22:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone1.gnilink.net!washdc3-snf1!washdc3-snh1.gtei.net!denver-snf1.gtei.net!news.gtei.net!namche.sun.com!sunnews1.Eng.Sun.COM!engnews1.eng.sun.com!taumet!clamage From: Daniel Miller Newsgroups: comp.std.c++,comp.lang.c++.moderated Subject: Re: A humble attempt to suggest alignment support for C++ Date: 30 May 2002 16:17:19 GMT Organization: Tellabs Lines: 131 Approved: stephen.clamage@sun.com (comp.std.c++) Message-ID: <3CF3CD9A.9090403@tellabs.com> References: <3CEA1A08.C6D95CC7@lmf.ericsson.se> NNTP-Posting-Host: taumet.eng.sun.com X-NNTP-Posting-Host: netlab.cs.rpi.edu X-Original-Date: Tue, 28 May 2002 13:34:02 -0500 X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPPZAoEHMCo9UcraBAQH1awIAiSZ0mTBixQb8CaP292koOAg4F+0CQ2Uh a+C7xNhvBC33LNWYojLtkr+JwMBxRK89KuhwbVN/zMwg3py0sBoBSA== =36NJ X-Approved-For-Group: hsutter@acm.org comp.lang.c++.moderated X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Content-Length: 4771 Originator: clamage@taumet Xref: archiver1.google.com comp.std.c++:11706 comp.lang.c++.moderated:44250 Attila Feher wrote: [...snip...] > Suggestion for new aligment language features for C++ > ===================================================== [...snip...] > Solution #2: > ------------ > > This solution requires a new, special keyword in the declarations, > hides all the know-how, and therefore a bit more complicated for the > implementors but much easier for the users. And it is less flexible > than #1, since with #1 I can even create a T *tp with align, then say > Y *yp=align( tp+1); and position a Y after the T in the memory. > > This solution would enable the coder to change alignment of any type On certain processors, certain data-types must be aligned in certain ways or else a fault occurs. On such processors where misalignment precipitates such a fault, that fault is typically harshly abortive outside of C++'s direct control/inhibition, such as dumping core memory in UNIX-family operating systems. One typically sees such harsh misalignment faulting on processors outside of the CISC world. CISC processors typically permit suboptimal alignments with a performance penalty. Many RISC & VLIW processors are not so permissive in an effort to save on silicon by reducing nonessential features, in that they generally require a nonaggregate scalar datum whose sizeof is k bytes to be aligned on an address s where s mod k == 0. > or > just char arrays in declarations. As it seems it is enough for just > char arrays, but you may see a good reason for open it up to arrays or > any other type. The following could be "opened up" only to a type T where sizeof(T) is a multiple of sizeof the type being declared. My example demonstrations of troublesome cases follows. > It could look something like this: > > align_as char T_arr[sizeof(T)*S]; For example, if the type being declared were to be a 16-bit short and T were to be an 8-bit char on a particular platform (whose shorts are two octets and whose chars are one octet), then use of that datum would cause degraded performance on certain processors and cause a fault on other processors for any 16-bit address s where s % sizeof(short) != 0 which would occur for 8-bit-char-based alignments of s % sizeof(16-bit short) == 1. Similarly, if the type being declared were to be a 32-bit int and T were to be an 80-bit double on a particular platform (with such sizes of scalar datatypes and char is 8-bit), then use of that datum would cause degraded performance on certain processors and cause a fault on other processors for any 80-bit address s where s % sizeof(32-bit int) != 0 which would occur for 80-bit-double-based alignments of s, where s is in the set {10k} where k is an element of the set of nonnegative integers. > So align_as would be a sort of "storage specifier like thing", > possibly behaving the same as static from syntax point of view. > Except that it would not "collide" with any storage specifiers, since > it is a different > thing: alignment specifier. [...snip...] > Conclusion: > ----------- > > I see many people struggling with alignment issues. With the current > set of language support (nil), we cannot solve this problem portably. Portable solutions to the alignment-detection problems exist, but can be extremely arcane, involving much typecasting & pointer arithmetic to discover what this compiler on this platform is doing to the pad-bytes when type x is declared after type y. A knowledge-base can be built-up at run-time via investigation of const char* value of various static or file-scope data-structures whose fields represent the the combination of types whose alignment-pairings are of interest. Portable solutions to the alignment-imposing problems exist, but can be extremely arcane, involving much typecasting, much pointer arithmetic, and many invocations of default placement operator new. What doesn't currently exist within the C++ standard is *simple* and *direct* portable solutions to the various alignment-discovery or alignment-control problems. > Adding this max_align(), align() and align_as to the language we > can allow people to save the dynamic memory allocation and still have > a rather STL like container: but on the stack, which is thread safe, > not like the heap/free-store. [...snip...] [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ] [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]