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
th
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 wit
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 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
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
http://lists.freepascal.org/mail
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 ex
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 multiplicatio
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() funct
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 maillis
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/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 m
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 m
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 suitab
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 me
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, but
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 in
16 matches
Mail list logo
