🚀 go-pugleaf

Michael Spertus (mps@geodesic.com) wrote:
: In article <4ccbdb$5v6@fg70.rz.uni-karlsruhe.de>,
: Thomas Koenig <ig25@mvmap66.ciw.uni-karlsruhe.de> wrote:
: >
: >I know of no compiler which is as brain-damaged as the one you describe;
: >when I encounter one, I'd tend to howl to the vendor.
: >-- 
: Many PC compilers have this problem (See the BYTEmark column in the
: December BYTE). The problem is that Win32 GlobalAlloc(), which is
: what most allocators use to get their arenas, returns a 32-bit aligned
: pointer. Most standard library implementations will pass through this
: alignment (probably because the implementor does not realize that
: GlobalAlloc() does not align very well so that code for an sbrk()
: based allocator cannot be used without change. They may also be unaware
: that Pentium PCs use 64 bits data buses). This problem is magnified
: because the Pentium (apparently) drops into microcode on nonaligned
: loads, so that nonaligned floating point benchmarks are over 300%
: slower.

This reminds me of a discussion over could calloc use the size parameter
as a hint to give different alignment to malloc. For example:
    calloc( N, sizeof( float ) )
could recognize the sizeof float and give 64 bit alignment in this case.
I recall the conclusion was that it could do this, but did not have to.
   
--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom