Whoops, yes. As Brian reminded me, it was probably double alignment, not pointers, that was the issue on the old Suns.
-pd On Aug 29, 2013, at 21:11 , peter dalgaard wrote: > > On Aug 29, 2013, at 20:37 , Hadley Wickham wrote: > >>> Not to be picky, but that is not the point. The alignment is due to the >>> attrib pointer which is at offset 8 despite the fact that there is only a >>> 4-byte element in front of it. Maybe for better illustration, this is the >>> layout on 64-bit machines: >> >> Ok, thanks for the clarification. >> >>> >>> * 4 bytes: sxpinfo header (= 32 bits) >>> * 4 bytes: --- padding so next ptr is aligned --- >>> * 8 bytes: pointer to attributes >>> * 8 bytes: pointer to next node >>> * 8 bytes: pointer to previous node >>> * 4 bytes: length >>> * 4 bytes: true length >>> >>> = 40 bytes >>> >>> This is already aligned so the payload alignment doesn't any extra padding >>> so that has no effect at all. >> >> Do pointers always have to be aligned? > > I think that is architecture/compiler specific, but usually aligned pointers > are loaded into memory in one clock cycle whereas unaligned ones take two, > insofar as the architecture allows it at all. > > Back in the days when Sun machines went 64 bit (1993 or so?), there was an > issue with dyn.loading into Splus, where it was passing unaligned pointers > and gcc was expecting them to be aligned. Basically, it became a toss-up > whether dyn.load calls would work or not... > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd....@cbs.dk Priv: pda...@gmail.com > > > > > > > > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
