On 03/04/10 13:12, Jonas Maebe wrote:
On 03 Apr 2010, at 14:09, Micha Nelissen wrote:
Do C memory managers guarantee any alignment anyway? Not for SSE (16 bytes) I'm
sure, but 8 bytes I don't know.
From Linux' malloc man page:
For calloc() and malloc(), the value returned is a pointer to
On 08 Apr 2010, at 15:05, C Western wrote:
How about an alternative implementation, without the integer
recording size? I had a quick try at this - the only use of the
MemSize routine in fpc+lazarus seems to be in an optimization in
resizing strings. If this routine is adjusted to cope
On 08/04/10 14:12, Jonas Maebe wrote:
On 08 Apr 2010, at 15:05, C Western wrote:
How about an alternative implementation, without the integer recording
size? I had a quick try at this - the only use of the MemSize routine
in fpc+lazarus seems to be in an optimization in resizing strings. If
On 04/03/2010 02:12 PM, Jonas Maebe wrote:
From Linux' malloc man page:
For calloc() and malloc(), the value returned is a pointer to the allo-
cated memory, which is suitably aligned for any kind of variable, or
NULL if the request fails.
Hmm. What does suitable mean ? With many
On 06 Apr 2010, at 12:00, Michael Schnell wrote:
On 04/03/2010 02:12 PM, Jonas Maebe wrote:
From Linux' malloc man page:
For calloc() and malloc(), the value returned is a pointer to the
allo-
cated memory, which is suitably aligned for any kind of variable, or
NULL if the request fails.
On 04/06/2010 01:07 PM, Jonas Maebe wrote:
No, calloc simply zeroes the allocated memory.
So why does it provide a size argument ? Just to zero the information it
would suffice to give it a byte count as with malloc().
-Michael
___
fpc-devel maillist
In our previous episode, Michael Schnell said:
No, calloc simply zeroes the allocated memory.
So why does it provide a size argument ? Just to zero the information it
would suffice to give it a byte count as with malloc().
I don't know, but the FreeBSD manpage says:
The calloc() function
On 06 Apr 2010, at 13:49, Michael Schnell wrote:
On 04/06/2010 01:07 PM, Jonas Maebe wrote:
No, calloc simply zeroes the allocated memory.
So why does it provide a size argument ?
One argument I know if is to prevent overflows, because size_t is an
unsigned type while most
On 04/06/2010 02:01 PM, Marco van de Voort wrote:
I don't know, but the FreeBSD manpage says:
The calloc() function allocates space for number objects, each size bytes
in length. The result is identical to calling malloc() with an
argument
of ``number * size'', with the
On 04/06/2010 02:15 PM, Jonas Maebe wrote:
the result of calloc has to be assignable to any other pointer type:
Is this not true for malloc(), as well ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 06 Apr 2010, at 15:11, Michael Schnell wrote:
On 04/06/2010 02:15 PM, Jonas Maebe wrote:
the result of calloc has to be assignable to any other pointer type:
Is this not true for malloc(), as well ?
Yes, but I was only trying to illustrate that the element size
parameter of calloc is
I notice that the cmem unit does not align memory in the same way as the
default unit - removing the cmem unit makes a factor of two difference
in the speed of some double precision matrix code. (My system is i386).
Inspecting the cmem unit indicates the issue is the extra bytes
allocated for
On 03 Apr 2010, at 13:00, C Western wrote:
I notice that the cmem unit does not align memory in the same way as the
default unit - removing the cmem unit makes a factor of two difference in the
speed of some double precision matrix code. (My system is i386). Inspecting
the cmem unit
C Western wrote:
Inspecting the cmem unit indicates the issue is the extra bytes
allocated for the count - is this really needed? Or do we have to
allocate more bytes for blocks that are a multiple of 8?
Do C memory managers guarantee any alignment anyway? Not for SSE (16
bytes) I'm sure,
In our previous episode, Jonas Maebe said:
Or do we have to allocate more bytes for blocks that are a multiple of 8?
FPC's default memory manager even guarantees 16 byte alignment (for vectors).
So a possible solution is to allocate 16-sizeof(ptruint) bytes more?
for 32-bit that would mean:
On 03 Apr 2010, at 14:09, Micha Nelissen wrote:
Do C memory managers guarantee any alignment anyway? Not for SSE (16 bytes)
I'm sure, but 8 bytes I don't know.
From Linux' malloc man page:
For calloc() and malloc(), the value returned is a pointer to the allo-
cated memory, which is
Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
Or do we have to allocate more bytes for blocks that are a multiple of 8?
FPC's default memory manager even guarantees 16 byte alignment (for vectors).
So a possible solution is to allocate 16-sizeof(ptruint) bytes more?
17 matches
Mail list logo
