adr@quiche.cs.mcgill.ca (Alain DURAND) (09/21/90)
Hello,
I've troubles with word alignments on different unix machine:
sizeof(struct foo) doesn't return the same thing on a sun3, sun386i
and sparc. Is there an option to set at compilation time or somewere
in the kernel to fix that?
thanks for any answer, please reply by E-Mail at:
adr@quiche.cs.mcgill.cabenyukhi@motcid.UUCP (Ed Benyukhis) (09/25/90)
In article <5020@quiche.cs.mcgill.ca>, mikey@quiche.cs.mcgill.ca (Michael GALLOP) writes: > Please note: The poster is only a grad student at Mcgill and does not reflect > the undergrad education :- ) At least he is asking relevant questions. You, on the other hand, do not have manners and enough education as well. Grow up!!!! And while you are at it, read some computer and compiler architecture literature. > > > Well Alain. There are several different factors. First off when dealing with > any two machines, your request will likely return different values. > > > One of the reasons-perhaps the main one- is the different architectures in > the CPUs of the machines. From what I remember 80X86 swaps the bytes around > from the way the SPARC deals with them Endianess has absolutely nothing to do with the data alignment rules. You have to understand the difference between the alignment restrictions of a machine and the alignment policy of the compiler. Contrary to what you are saying, some machines, like INTEL 80x86 and VAX, have NO alignment restrictions. Data objects of any type can be referenced at any address boundary without causing a machine exception. Even on such machines, however, data access may be more efficient at certain alignment boundaries. For each type, the alignment policy of the compiler determines what addresses the compiler will use in placing data objects declared to be of that type. The compiler implementor's freedom in choosing an alignment policy is limited by the alignment restrictions of the hardware. The alignment policy may be stricter than the machine's alignment restrictions for reasons of efficient access. A machine may be able, for instance, to access a long integer beginning at any byte boundary, yet it may access longs more quickly if their first byte's address is a multiple of 4 ....... In general, the alignment policy must at least be as strict as the hardware's alignment restrictions. However, different COMPILERS for the SAME machine may have different alignment policies. Each compiler chooses an alignment policy based on the trade off of space efficiency vs. run-time efficiency. > > > More importantly is the difference in word size. An 80386 is a 32 bit machine > -in some modes. In fact all of these are 32 bit machines. However the > register addressing is different on each one. The Sparc uses circular > addressing, whereas the i386 uses a form of virtual addressing. > > Further, an important factor is the overhead of your C compiler, your OS. > These _MIGHT_ ( probably won't) affect the result returned.... > This, coupled with the different ways that each OS allocates memory > will result in your observations. > This is off the wall. The processor's programming model and its addressing modes have no bearing on the alignment, other than ones described above. I don't think you have enough knowledge to contribute any more to this discussion, let alone, "reflect and undergraduate education". You do, however, behave like an undergraduate. > > Why, though are you asking ? You can't magic number a (Not can't- shouldn't) > malloc. So you should > if ( ( malloc ( sizeof ( foo ) ) ==NULL ) > or whatever is needed. > > As for patching it in the kernel, I couldn't possibly see why, or how, you'd > do that. By hard wiring a value like that in the kernel, you cause havoc in > the rest of the OS. Especially in a 386. If you were to do that on a 386 in > 386 protected mode, or, worse in virtual 8086 mode, the page frame would > cause a memory fault- I should know, I spent many hours chasing my mistake > on that one I tried to align with a magic number :- ( -and dump the machine. regards, Edward Benyukhis Motorola, CID (Cellular Infrastructure Division) of RTSG (708)632-4658
willr@ntpdvp1.UUCP (Will Raymond) (09/26/90)
> At least he is asking relevant questions. You, on the other hand, do not have manners > and enough education as well. Grow up!!!! And while you are at it, read some > computer and compiler architecture literature. > I don't think you have enough knowledge to contribute any more to this > discussion, let alone, "reflect and undergraduate education". You do, > however, behave like an undergraduate. > > Edward Benyukhis > Motorola, CID (Cellular Infrastructure Division) of RTSG > (708)632-4658 Flame On. Your response is not in keeping with a wizardly attitude ( if that is your claim ). Additionally, while 'some undergraduates' seem to below your standards I can't help but notice he kept his post to 80 chars/line while you on the other-hand..... Enough Said. ******* Will Raymond - Northern Telecom NTP in RTP | | ~ ~ | | . O o . Work: ...uucp!rti!ntpdvp1!willr | .V. | Fun: ...uucp!cs.unc.edu!raymond ._ _. | U | I speak for myself.
benyukhi@motcid.UUCP (Ed Benyukhis) (09/26/90)
In article <633@ntpdvp1.UUCP>, willr@ntpdvp1.UUCP (Will Raymond) writes: > > Flame On. Your response is not in keeping with a wizardly attitude ( if > that is your claim ). Additionally, while 'some undergraduates' > seem to below your standards I can't help but notice he kept his > post to 80 chars/line while you on the other-hand..... > > Enough Said. > Perhaps my response was harsh. But when I see references like the one bellow, I start to flame. >> Please note: The poster is only a grad student at Mcgill and does not reflect the >> undergraduate education :- ) If the above was meant as a harmless joke, I appologize for my remarks. It looked, however, like the guy has tried to position himself above this "other graduate student" who initiated the thread. I was simply trying to vindicate him. It is not the original question that drew my criticizm, but, rather, the way the answer was provided i.e. in a blatantly tactless and discrespectfull manner. Moreover, I want to emphasize the importance of being able to ask questions, reagardless of how "stupid" they may seem, in this forum. As to whether or not I am making any claims ..... I did not think so. I only think that my comments were technically correct, although offensive, yours, however, " ... he kept his post to 80 chars/line while you ..." have no identifiable technical content at all. Enough Said. Ed Benyukhis, Motorola CID. (708)632-4658
meissner@osf.org (Michael Meissner) (09/27/90)
In article <4711@navy19.UUCP> benyukhi@motcid.UUCP (Ed Benyukhis) writes: | ..... However, different COMPILERS for the SAME machine may have different | alignment policies. Each compiler chooses an alignment policy based on the trade off | of space efficiency vs. run-time efficiency. Or depending on the phase of the moon, or whether the compiler writer wanted to be compatible with something else, or what have you. For example, you might chose to make things more strictly aligned then necessary on the hunch that the next generation of chips will run faster if strict alignment is used. For example, I believe that on a 8088 which has an 8 bit bus, a 16-bit item will take the same number of cycles no matter what the alignment, but consider a 8086 which has a 16 bit bus, aligning 16 bit items on 16 bit boundaries will go faster I believe. Note I'm hedging in the example, because I do not use intel chips in normal use, so I'm not as familar with them.... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
cdm@gem-hy.Berkeley.EDU (Dale Cook) (09/27/90)
In article <5020@quiche.cs.mcgill.ca>, mikey@quiche.cs.mcgill.ca (Michael GALLOP) writes: |> Sorry, my rn is busted...I gotta do this by hand. |> In article 20631 <4046@quiche.cs.mcgill.ca > (adr@quiche.cs.mcgill.ca) |> (Alain Durand) writes: |> > |> >Hello, |> > |> > I've troubles with word alignments on different unix machine: |> >sizeof(struct foo) doesn't return the same thing on a sun3, sun386i |> >and sparc. Is there an option to set at compilation time or somewere |> >in the kernel to fix that? |> >thanks for any answer, please reply by E-Mail at: |> > |> >adr@quiche.cs.mcgill.ca |> |> |> |> |> |> Please note: The poster is only a grad student at Mcgill and does not reflect |> the undergrad education :- ) |> |> |> Well Alain. There are several different factors. First off when dealing with |> any two machines, your request will likely return different values. |> |> |> One of the reasons-perhaps the main one- is the different architectures in |> the CPUs of the machines. From what I remember 80X86 swaps the bytes around |> from the way the SPARC deals with them |> |> |> More importantly is the difference in word size. An 80386 is a 32 bit machine |> -in some modes. In fact all of these are 32 bit machines. However the |> register addressing is different on each one. The Sparc uses circular |> addressing, whereas the i386 uses a form of virtual addressing. |> |> Further, an important factor is the overhead of your C compiler, your OS. |> These _MIGHT_ ( probably won't) affect the result returned.... |> This, coupled with the different ways that each OS allocates memory |> will result in your observations. |> |> |> Why, though are you asking ? You can't magic number a (Not can't- shouldn't) |> malloc. So you should |> if ( ( malloc ( sizeof ( foo ) ) ==NULL ) |> or whatever is needed. |> |> As for patching it in the kernel, I couldn't possibly see why, or how, you'd |> do that. By hard wiring a value like that in the kernel, you cause havoc in |> the rest of the OS. Especially in a 386. If you were to do that on a 386 in |> 386 protected mode, or, worse in virtual 8086 mode, the page frame would |> cause a memory fault- I should know, I spent many hours chasing my mistake |> on that one I tried to align with a magic number :- ( -and dump the machine. I just finished working a file transfer project, and had to deal with exactly this issue. Aside from obvious considerations of differring word sizes, I found the most important consideration to be the "padding" each compiler adds to the end of the structure. Some pad to floating point word boundaries, some to character boundaries, others pad to the end of the largest item allocated in the structure. Typically, the padding comes into play for structures containing character strings, but short int is another to watch out for. Neither the United States Government nor the Idaho National Engineering Laboratory nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.