Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!iecc!compilers-sender From: pardo@june.cs.washington.edu (David Keppel) Newsgroups: comp.compilers Subject: Re: SPARC tagged data Keywords: architecture, C Message-ID: <91-05-075@iecc.cambridge.ma.us> Date: 10 May 91 18:12:12 GMT References: <91-05-073@iecc.cambridge.ma.us> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: pardo@june.cs.washington.edu (David Keppel) Organization: Computer Science & Engineering, U. of Washington, Seattle Lines: 35 Approved: compilers@iecc.cambridge.ma.us henry@zoo.toronto.edu (Henry Spencer) writes: >[It may be difficult to pass structures to C anyway because of > other design decisions made differently.] Indeed, it may be difficult to pass structures between C and C if the fragments were compiled with different compilers (e.g., libraries). Problems include: * Structure passing (most notably return) conventions * Alignment * Padding So, for example, a compiler for a machine that allows unaligned fetches (e.g., the VAX) might implement struct { char c; int i; } as: one byte followed by 4 bytes, non-padded one byte followed by 4 bytes, padded to 8 bytes 1 byte, padded to 4 bytes, followed by 4 bytes I think these choices are all legal, but I wouldn't swear to it. The point is that a compiler may legitimately derive different struct layouts from one hadware specification. The second one is pretty silly, but the third may actually improve performance by reducing the number of unaligned fetches. So even if all the world programmed in C, we still wouldn't have solved the interoperability problem :-) ;-D on ( Inter-city commuting? Inter-face computing ) Pardo -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.